The Onchain Brief is here| Subscribe to our monthly newsletter

FAQs

Securing Onchain Systems

Our security audits and continuous security work for crypto-native teams.

Smart Contract Security & Audits

Because smart contracts directly manage real value onchain, vulnerabilities in their code can result in significant financial losses. Common risks include logic errors, access control flaws, reentrancy attacks, oracle manipulation, and issues with upgradability. Unlike traditional software, smart contracts are often immutable once deployed, meaning vulnerabilities cannot simply be patched after the fact. This makes rigorous security assessment before deployment essential.
A smart contract security audit is a comprehensive review of a smart contract's code, architecture, and business logic, conducted by experienced security researchers. The goal is to identify vulnerabilities, assess design decisions, and provide recommendations before a contract is deployed onchain. For financial institutions building onchain, audits are a critical component of institutional-grade risk management.

OpenZeppelin's security audit process is structured across four stages:

  1. Pre-Audit: Security researchers review project documentation and test suites, with OpenZeppelin AI surfacing routine and lower-severity issues early so the team can focus on the most critical vulnerabilities.
  2. Security Audit: A comprehensive review of the system's architecture and codebase, with every line of code inspected by at least two security researchers. Advanced techniques including fuzzing and invariant testing are applied where needed.
  3. Fix Review: Researchers meticulously review all remediated issues and engage directly with the development team to ensure fixes are sound and well-understood.
  4. Ongoing Support: OpenZeppelin maintains an open communication channel post-audit, providing long-term consultation as the protocol evolves.
OpenZeppelin has uncovered 700+ critical and high-severity vulnerabilities across a wide range of protocols. Notable findings include critical issues in ZK-verifier contracts, cross-domain transaction flaws, fraud-proof verification errors, fee mismanagement, and reward system abuses. OpenZeppelin has also identified five zero-day vulnerabilities, helping protect $15 billion in funds at risk across affected protocols.
OpenZeppelin secures a broad range of onchain systems, including onchain exchanges (DEXs), L1-L2 bridges, lending protocols, oracle systems, account abstraction implementations, stablecoins, governance contracts, and financial institution infrastructure. Notable audit relationships include Coinbase, Uniswap, Aave, and the Ethereum Foundation, alongside leading Layer 1 and Layer 2 networks.
OpenZeppelin pioneered smart contract security in 2015 and has since established the industry standard for code review. Its audit team brings together expertise in PhD-level mathematics, cryptography, low-level EVM operations, and finance, making it uniquely equipped to assess the complex onchain systems that financial institutions are building. With $250 billion+ in total value secured and 900+ security engagements completed since 2015, OpenZeppelin provides the institutional-grade security and long-term partnership that financial institutions require.

Several factors distinguish an OpenZeppelin Security Audit:

  • Depth of review: Every line of code is inspected by at least two security researchers, supported by cryptographers, advanced testing engineers, and security analysts as needed.
  • AI-native methodology: OpenZeppelin AI surfaces routine and lower-severity issues early, ensuring senior researchers focus on the most critical risks.
  • Client-centered approach: OpenZeppelin engages directly with client teams throughout the audit process, ensuring both business objectives and code security are achieved.
  • Long-term relationships: A decade of continuity since 2015, with zero exploits in fully-remediated audited code, reflecting a model built on sustained trust rather than one-time engagements.

Blockchain Infrastructure Security

Blockchain infrastructure refers to the offchain and onchain systems that support the operation of blockchain networks and applications. This includes node software, APIs, relayers, bridges, sequencers, indexers, and other backend components that enable blockchain protocols to function reliably and securely. For financial institutions building onchain, robust infrastructure is as critical as the smart contracts themselves.
Onchain infrastructure refers to smart contracts and logic that live directly on the blockchain, while offchain infrastructure refers to the supporting systems that interact with the blockchain but run outside of it. Examples of offchain components include backend services, oracles, key management systems, and transaction relayers. Both layers must be secured to protect the integrity of onchain financial systems.
Even the most secure smart contract can be compromised by a single vulnerable offchain component. Offchain codebases are often large and complex, making comprehensive security review difficult. Additionally, because offchain code can be updated frequently, each new release introduces the potential for new vulnerabilities. Malicious actors actively monitor for flaws in production systems, meaning teams must identify and address issues before they can be exploited.
For financial institutions operating onchain, infrastructure security is a core component of risk management and compliance. Vulnerabilities in offchain systems, such as key management, transaction processing, or data feeds, can expose digital assets and onchain financial operations to significant risk. Institutional-grade security requires protecting the full stack, not just the smart contract layer.
Security review should cover any offchain component that interacts with or supports onchain systems. This includes node clients, bridge infrastructure, sequencers, relayers, oracles, APIs, key management systems, and backend services. Each component carries its own risk profile and should be assessed based on its criticality to the broader system.
A blockchain infrastructure security audit is a targeted review of the offchain systems that support a blockchain protocol or application. Unlike a smart contract audit, which focuses on Solidity or other onchain code, an infrastructure audit examines backend codebases, system architecture, and the interactions between offchain and onchain components, identifying vulnerabilities that could undermine the security of the broader system.
OpenZeppelin takes a tailored, risk-weighted approach to infrastructure security. Every review is led by veteran researchers with deep expertise in blockchain infrastructure across a range of languages and technologies. Rather than applying a one-size-fits-all methodology, OpenZeppelin grades each component for criticality and complexity, focusing time and resources on business-critical logic and the areas where exploits are most likely to occur.

OpenZeppelin offers two distinct engagements depending on a project's needs and stage of development.

  1. A security assessment identifies high-level flaws, architectural problems, and the most critical areas requiring deeper review. It is particularly well-suited for projects in late-development stages or with very large codebases, and can be a critical first step before moving into a full audit.
  2. A security audit is a deep, comprehensive code review that uncovers specific security issues and provides recommendations for safe deployment. Audits are typically performed in phases across multiple subscopes identified during the assessment.
OpenZeppelin's infrastructure security practice has uncovered 121+ vulnerabilities across 14+ infrastructure audits, helping secure $1.6 billion+ in total value locked. Findings span a range of issue types including architectural flaws, logic errors in offchain components, and vulnerabilities in the interaction layer between offchain systems and onchain contracts.
OpenZeppelin's infrastructure security researchers have deep expertise across a broad range of languages and technologies used in blockchain infrastructure development, including but not limited to Go, Rust, and TypeScript. The team assesses codebases based on the specific technologies used by each client, ensuring review depth regardless of the underlying stack.

OpenZeppelin uses a risk-weighted scoping approach, grading each infrastructure component for criticality and complexity before the engagement begins. This ensures that time and budget are directed toward the systems that matter most, rather than low-impact boilerplate code. The result is a targeted, cost-effective engagement that provides maximum security value without exceeding clients' budgets.

Financial institutions deploying onchain systems face a unique challenge: their infrastructure codebases are often large, complex, and subject to frequent updates. Each change introduces potential risk. An infrastructure security audit provides the systematic, expert-led review needed to identify vulnerabilities before they can be exploited, supporting the risk management and compliance standards that financial institutions require. OpenZeppelin's infrastructure audits are designed to meet that standard, providing institutional-grade security across the full onchain stack.

Zero-Knowledge Proofs & Cryptography

A zero knowledge proof (ZKP) is a cryptographic method that allows one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. In practical terms, ZKPs enable systems to verify computations or claims, such as a user's eligibility, identity, or transaction validity, without exposing the underlying data. This combination of verifiability and privacy makes ZKPs one of the most significant cryptographic innovations in onchain finance.
At a high level, a ZKP involves two parties: a prover and a verifier. The prover generates a cryptographic proof demonstrating that they know or have computed something correctly, without disclosing the actual input or data. The verifier can then confirm the proof's validity with a high degree of mathematical certainty. Modern ZKP systems such as zk-SNARKs and zk-STARKs have made this process efficient enough to be practical for blockchain applications at scale.

zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge) and zk-STARKs (Scalable Transparent Arguments of Knowledge) are two widely used ZKP systems, each with distinct tradeoffs.

zk-SNARKs produce very small, fast-to-verify proofs but require a trusted setup ceremony to generate the cryptographic parameters used in proof generation. A compromise of this setup could undermine the system's security.

zk-STARKs eliminate the need for a trusted setup, making them more transparent and resistant to certain classes of attack. They also offer better scalability, though they typically produce larger proofs than zk-SNARKs. Both are actively used in blockchain infrastructure today.

ZKPs have a broad range of applications in the blockchain ecosystem, including privacy-preserving transactions, identity verification, regulatory compliance, and scalability. Their most prominent application is in ZK-rollups, which use ZKPs to bundle large numbers of transactions offchain and submit a single compressed proof to the base layer blockchain, significantly increasing throughput without sacrificing security.
A ZK-rollup is a Layer 2 scaling solution that uses zero knowledge proofs to process transactions offchain and settle them onchain with cryptographic finality. For onchain financial infrastructure, ZK-rollups offer a compelling combination of scalability, security, and cost efficiency. They enable financial institutions to process high volumes of transactions at lower cost while maintaining the security guarantees of the underlying blockchain, making them increasingly relevant for institutions exploring onchain capital markets and settlement infrastructure.
Privacy is a fundamental requirement for financial institutions operating onchain. ZKPs enable transactions and financial data to be verified without exposing sensitive details to the public blockchain, allowing institutions to meet confidentiality obligations while still benefiting from the transparency and auditability of onchain infrastructure. Use cases include private settlement, confidential asset transfers, and compliance verification, where an institution can prove regulatory adherence without disclosing underlying transaction data.
Despite their cryptographic strength, ZKP systems introduce a distinct set of security risks. Vulnerabilities can arise in the implementation of ZK-verifier contracts, the circuit logic used to encode computations, and the cryptographic libraries underlying the proof system. Bugs in any of these components can be difficult to detect and potentially catastrophic in their impact. For financial institutions deploying ZKP-based infrastructure, rigorous security assessment of the full ZKP stack is essential.
Yes. OpenZeppelin's security researchers have deep expertise in auditing ZKP systems, including ZK-verifier contracts, circuit implementations, and ZK-rollup infrastructure. OpenZeppelin has identified critical vulnerabilities in ZK-verifier contracts, including issues in the Linea ZK-verifier and other ZK-rollup implementations, making it one of the few security firms with demonstrated, battle-tested experience in this highly specialized area.
ZKPs offer a technically elegant solution to one of the central tensions in onchain finance: the need to demonstrate regulatory compliance without compromising client confidentiality. Using ZKPs, financial institutions can prove that a transaction meets regulatory requirements, such as AML checks or accredited investor status, without revealing the underlying data to the blockchain or to counterparties. This capability is increasingly relevant as regulators develop frameworks for tokenized assets and onchain financial services.
Adoption of ZKP technology in financial services is accelerating. Major blockchain networks including Ethereum, ZKsync, Scroll, and Linea have built ZK-based infrastructure into their core architecture, and financial institutions are beginning to explore ZKP-enabled applications for settlement, compliance, and privacy-preserving transactions. As the tooling, standards, and security practices around ZKPs mature, they are expected to become a foundational component of the next generation of digital assets and financial services infrastructure.

Blockchain Attack Vectors & Exploits

Smart contract vulnerabilities arise from flaws in code logic, design decisions, or implementation that can be exploited by malicious actors. The most commonly encountered include reentrancy attacks, where an external contract repeatedly calls back into a vulnerable function before the initial execution completes; integer overflow and underflow errors, where arithmetic operations produce unexpected results; access control weaknesses, where functions or state variables are accessible to unauthorized parties; and logic errors in business rules, where the contract behaves in unintended ways under specific conditions. Each of these can result in the loss or manipulation of onchain assets if left unaddressed.
A reentrancy attack occurs when a malicious contract repeatedly calls back into a vulnerable smart contract before the initial function execution has completed, exploiting the contract's state before it has been updated. This class of vulnerability was responsible for the 2016 DAO hack, one of the most significant security incidents in blockchain history. Reentrancy vulnerabilities are a standard focus of smart contract security audits and can be mitigated through careful state management and the use of battle-tested design patterns.
Access control vulnerabilities occur when smart contract functions that should be restricted to authorized parties, such as contract owners or administrators, are incorrectly exposed to any caller. These flaws can allow malicious actors to perform privileged actions such as minting tokens, draining funds, or modifying critical contract parameters. Robust access control design, using well-established patterns and thoroughly audited implementations, is a fundamental requirement of secure smart contract development.
Many smart contracts are designed to be upgradeable, allowing developers to deploy fixes or new functionality after initial deployment. While upgradability adds flexibility, it also introduces risk. Poorly implemented upgrade mechanisms can allow unauthorized parties to take control of a contract, introduce new vulnerabilities, or manipulate storage layouts in ways that corrupt contract state. Upgradability patterns must be carefully designed and audited to ensure they do not become an attack surface in their own right.
Offchain attack vectors refer to vulnerabilities in the systems and components that support a blockchain protocol but operate outside the blockchain itself. These include backend APIs, node infrastructure, key management systems, relayers, bridges, and indexers. Because offchain components interact directly with onchain systems, a vulnerability in any of these layers can be exploited to manipulate onchain state, steal assets, or disrupt protocol operations, even if the smart contracts themselves are secure.
Blockchain bridges are protocols that enable assets and data to be transferred between different blockchain networks. They are among the most complex and high-value components in the blockchain ecosystem, and have historically been the target of some of the largest exploits in the industry. Bridge vulnerabilities can arise in the smart contracts governing asset locking and minting, the offchain relayer systems that pass messages between chains, and the cryptographic verification mechanisms that validate cross-chain state. The combination of complexity, high value, and cross-chain interaction makes bridges a critical area for security assessment.
Blockchain node infrastructure, including the client software that validates and propagates transactions, presents its own set of security risks. Vulnerabilities in node clients can be exploited to cause network disruption, enable double-spend attacks, or manipulate the view of blockchain state presented to applications. For financial institutions running their own node infrastructure, or relying on third-party providers, the security of the underlying node layer is an important component of overall onchain security posture.
Blockchain oracles are systems that supply onchain smart contracts with external data, such as asset prices, interest rates, or real-world events. Oracle manipulation attacks exploit the dependency of smart contracts on this external data by artificially influencing the data feed, for example, by manipulating the price of an asset on a low-liquidity exchange that a protocol uses as a price source. Protocols that rely on a single or easily manipulable oracle source are particularly vulnerable. Robust oracle design, including the use of time-weighted average prices and multiple independent data sources, is a key mitigation.
A flash loan is an uncollateralized loan that is borrowed and repaid within a single blockchain transaction. While flash loans themselves are a legitimate DeFi primitive, they can be weaponized to amplify attacks against vulnerable protocols. In a flash loan attack, an attacker borrows a large sum of assets, uses them to manipulate market conditions or exploit a vulnerability in a target protocol, and repays the loan, all within a single atomic transaction. Flash loan attacks have been responsible for significant losses across DeFi protocols and highlight the importance of designing smart contracts to be resilient against large, instantaneous capital movements.
A governance attack occurs when a malicious actor accumulates enough governance tokens to pass proposals that benefit themselves at the expense of a protocol and its users. This can include draining the treasury, modifying critical protocol parameters, or upgrading contracts to malicious implementations. Governance attacks are particularly relevant for DeFi protocols with large onchain treasuries and token-weighted voting systems. Robust governance design, including timelocks, quorum requirements, and multisig controls, is essential to mitigating this risk.
Blockchain systems rely on cryptographic primitives, including hash functions, digital signature schemes, and zero knowledge proof systems, whose security depends on correct and careful implementation. Cryptographic vulnerabilities can arise from the use of weak or outdated algorithms, flawed implementations of sound algorithms, or subtle errors in the mathematical constructions underlying ZKP circuits. These vulnerabilities are often highly technical and difficult to detect through standard code review, requiring specialized expertise in cryptography and formal verification.
ZKP implementations introduce a distinct class of vulnerabilities that differ from those found in conventional smart contracts. Errors in ZK circuit logic can allow invalid proofs to be accepted as valid, enabling attackers to bypass verification checks entirely. Trusted setup ceremonies for zk-SNARK systems, if compromised, can undermine the security of the entire proof system. And vulnerabilities in ZK-verifier contracts, the onchain components that verify proofs, can be exploited to accept fraudulent state transitions. OpenZeppelin has identified critical vulnerabilities in ZK-verifier contracts across several major ZK-rollup implementations, underscoring the importance of specialized audit expertise in this area.
Private keys are the cryptographic credentials that control access to onchain assets and smart contract administration. If a private key is compromised, through phishing, malware, insecure storage, or insider threats, an attacker gains full control over the assets and contracts associated with that key. Unlike traditional financial systems where fraudulent transactions can sometimes be reversed, onchain transactions are typically irreversible. This makes private key security one of the most critical and consequential aspects of onchain operational security for financial institutions.
Social engineering attacks target the human layer of a security system rather than its technical components. In the blockchain context, this includes phishing attacks targeting developers or administrators with access to private keys or deployment infrastructure, supply chain attacks where malicious code is introduced through compromised development dependencies, and impersonation attacks targeting protocol teams or community members. Social engineering is a significant vector for onchain security incidents and requires organizational security practices, including access controls, multi-party authorization, and security awareness training, alongside technical safeguards.
A supply chain attack targets the software dependencies and development tooling used to build blockchain applications, rather than the application itself. If a widely used open-source library or development tool is compromised, malicious code can be introduced into many downstream projects simultaneously. For blockchain protocols and financial institutions building onchain, supply chain security requires careful management of software dependencies, regular audits of third-party libraries, and vigilance around the integrity of development environments.
OpenZeppelin's security researchers bring deep, specialized expertise across the full spectrum of blockchain attack vectors, from smart contract vulnerabilities and cryptographic flaws to offchain infrastructure weaknesses and DeFi-specific exploits. Every audit engagement begins with a thorough assessment of the system's architecture and threat model, identifying the attack surfaces most relevant to that specific protocol or application. This risk-weighted approach ensures that the most critical vulnerabilities receive the most focused attention.
OpenZeppelin combines manual code review with AI-native tooling to maximize vulnerability detection. OpenZeppelin AI surfaces routine and lower-severity issues early, freeing senior researchers to focus on complex, high-impact vulnerabilities. Advanced testing techniques including fuzzing and invariant testing are applied to stress-test system behavior under unexpected conditions. For cryptographic and ZKP components, OpenZeppelin draws on specialized expertise in formal verification and mathematical analysis that goes beyond the capabilities of conventional security tooling.
Blockchain attack vectors evolve continuously as new protocols, primitives, and attack techniques emerge. OpenZeppelin supports financial institutions in managing this ongoing risk through a combination of continuous security monitoring, post-deployment security support, and access to cutting-edge research that tracks the latest developments in onchain threats. This lifecycle approach to security ensures that institutions are not only protected at the point of deployment but remain resilient as the threat landscape evolves.

Onchain Security Best Practices

A security-first approach to smart contract development means treating security as a foundational design consideration rather than a final checklist item. In practice, this involves using well-established, audited libraries and frameworks as the basis for new contracts rather than writing functionality from scratch; applying established design patterns for access control, upgradability, and reentrancy protection from the outset; and involving security expertise early in the development process, before architectural decisions become difficult to reverse. The cost of remediating a vulnerability discovered in production is significantly higher than addressing it during development.
Writing smart contract logic from scratch introduces the potential for subtle vulnerabilities that even experienced developers may not anticipate. Audited libraries, such as OpenZeppelin's Contracts library, have been reviewed by security researchers, stress-tested across thousands of production deployments, and continuously maintained against the latest security research. Building on this foundation reduces the attack surface of a new contract significantly, allowing development teams to focus their effort on the custom logic specific to their application rather than reimplementing functionality that already exists in a battle-tested form.
Several design-level decisions have an outsized impact on smart contract security. Access control architecture, defining clearly which addresses can call which functions, should be established early and implemented using well-tested patterns. Upgrade mechanisms, if required, should be designed to minimize trust assumptions and include appropriate time delays. The scope of each contract should be kept as narrow as possible, reducing complexity and the potential for unexpected interactions. Dependencies on external contracts, oracles, or data sources should be minimized and carefully assessed for the risks they introduce.
The principle of least privilege holds that each component of a system should have access only to the functions and data it needs to perform its intended role, and no more. In smart contract development, this means restricting administrative functions to the minimum number of addresses necessary, avoiding the use of overly broad permissions, and ensuring that privileged roles cannot be assumed by unauthorized parties. Applying the principle of least privilege reduces the potential impact of a compromised key or account, limiting what an attacker can do even if they gain partial access to a system.
Before deploying a smart contract to a production environment, organizations should consider a range of security measures. These typically include comprehensive unit and integration testing covering both expected and edge-case behavior; static analysis using automated tools to identify common vulnerability patterns; fuzz testing to expose unexpected behavior under randomized inputs; invariant testing to verify that critical system properties hold under all conditions; and a thorough security audit conducted by experienced external researchers. The appropriate combination of these measures will depend on the complexity and risk profile of the system being deployed.
Fuzz testing is an automated testing technique that generates large volumes of randomized or semi-structured inputs to a system in order to identify unexpected behavior, crashes, or security vulnerabilities. In the context of smart contracts, fuzz testing can uncover edge cases that manual testing and static analysis may miss, particularly in complex financial logic where the interaction of multiple inputs can produce surprising results. Fuzz testing is most effective when combined with clearly defined invariants: properties that should always hold true regardless of input, and whose violation indicates a potential vulnerability.
Organizations can improve the quality and efficiency of a security audit by preparing thoroughly in advance. This typically involves ensuring that the codebase is complete and code-frozen for the audit scope, that comprehensive documentation of the system's architecture and business logic is available, that a full test suite is in place and passing, and that any known issues or areas of uncertainty have been flagged for the auditors. Engaging a security firm before the codebase is ready can result in auditors spending time on incomplete or unstable code rather than focusing on critical vulnerabilities.

Deployment is not the end of the security lifecycle; it is the beginning of the operational phase, during which real assets are at risk. Post-deployment monitoring allows teams to detect anomalous onchain activity that may indicate an exploit in progress, identify unexpected behaviors that were not anticipated during development or audit, and respond rapidly to emerging threats before they result in significant losses. The public and transparent nature of blockchain transactions means that potential attackers can monitor onchain activity just as defenders can, making real-time alerting and rapid response capabilities essential.

Effective post-deployment monitoring for onchain systems typically covers unusual transaction patterns, such as large or unexpected asset movements, abnormal function call volumes, or interactions from unfamiliar addresses; governance activity, including unexpected proposal submissions or voting patterns; changes to critical contract parameters or access control configurations; and events emitted by contracts that may indicate error conditions or boundary cases being reached. Automated alerting on these signals, combined with defined response procedures, enables teams to act quickly when anomalies are detected.
Timelocks and pausing mechanisms are important operational security controls for onchain systems. A timelock enforces a mandatory delay between the initiation of a privileged action, such as a contract upgrade or parameter change, and its execution, providing a window for teams and stakeholders to review and respond to potentially unauthorized changes. A pausing mechanism allows authorized parties to temporarily halt contract operations in the event of a detected vulnerability or ongoing exploit, limiting damage while a response is coordinated. Both controls should be designed carefully to avoid introducing new attack surfaces or creating undue centralization of control.
Effective onchain access control begins with a clear mapping of the roles and permissions required by a system, followed by implementation using well-tested patterns that enforce those permissions at the contract level. Key best practices include using role-based access control rather than single-owner patterns wherever possible; requiring multi-party authorization for the most sensitive administrative functions; implementing timelocks on privileged actions; regularly reviewing and auditing the list of addresses holding privileged roles; and establishing procedures for revoking access promptly when it is no longer required. Access control weaknesses are among the most commonly exploited vulnerabilities in onchain systems, making this an area that warrants careful and ongoing attention.
Privileged roles and administrative keys should be managed with the same rigor as the most sensitive credentials in any financial system. Best practices include distributing control across multiple parties using multisig or MPC arrangements, avoiding the use of single keys for high-impact administrative functions, storing key material in hardware security modules or equivalent secure environments, maintaining clear documentation of who holds which keys and under what conditions they can be used, and conducting regular reviews to ensure that access reflects current organizational requirements. The compromise of a privileged key in an onchain system can have immediate and irreversible financial consequences.
OpenZeppelin makes a range of resources available to developers building secure onchain systems. These include the open-source Contracts library with implementations of industry-standard token and governance patterns; Ethernaut, the leading interactive security training platform for smart contract developers; comprehensive documentation and developer guides; and contributions to Ethereum standards through the ERC and EIP process. For organizations requiring deeper support, OpenZeppelin's professional services team provides tailored security assessments, audit engagements, and ongoing security partnerships.

Formal Verification

Formal verification is a mathematically rigorous technique for proving that a program behaves correctly according to a formally specified set of properties. Unlike testing, which checks program behavior against a finite set of inputs, formal verification exhaustively analyzes all possible states and execution paths a program can take, providing a stronger guarantee that critical properties hold under every conceivable condition. In the context of onchain systems, where a single undetected bug can result in the irreversible loss of significant financial assets, formal verification represents one of the highest levels of assurance available.
Security auditing, testing, and formal verification are complementary rather than competing approaches, each providing a different type and degree of assurance. Testing verifies that a program behaves correctly for a specific set of inputs and scenarios. Security auditing combines manual code review, automated analysis, and expert judgment to identify vulnerabilities across a codebase. Formal verification goes further by mathematically proving that specified properties hold across all possible inputs and states. For the most critical components of onchain financial infrastructure, formal verification provides a level of certainty that testing and auditing alone cannot achieve.
Formal verification can be used to prove a range of properties about a smart contract or onchain system. These include safety properties, assertions that certain undesirable states can never be reached, such as a token supply exceeding a defined cap or an unauthorized address gaining administrative access; liveness properties, assertions that the system will eventually reach a desired state, such as a pending withdrawal being processable; and functional correctness properties, assertions that specific functions produce the correct output for all valid inputs. The properties being verified must be formally specified before verification can proceed, which itself requires a precise understanding of the system's intended behavior.
While formal verification provides strong mathematical guarantees, it has important limitations. It can only prove properties that have been explicitly specified, if a property is not formalized, it cannot be verified. The quality of the guarantees provided depends entirely on the accuracy and completeness of the formal specification, meaning that an incorrect specification can produce a verified system that still behaves incorrectly in practice. Formal verification is also resource-intensive, requiring specialized expertise and significant time investment, which means it is typically applied selectively to the most critical components of a system rather than to an entire codebase.
Fuzzing and formal verification both aim to uncover unexpected behavior in smart contracts, but through fundamentally different approaches. Fuzzing generates large volumes of randomized inputs to probe a system empirically, finding bugs by exploring many possible execution paths without guaranteeing exhaustive coverage. Formal verification, by contrast, mathematically proves that specified properties hold across all possible inputs and states, providing exhaustive coverage for the properties being verified. Fuzzing is faster and more broadly applicable, while formal verification provides stronger guarantees for the specific properties it targets. Both are valuable components of a comprehensive pre-deployment security program.
Formal verification is most appropriate for components where the cost of an undetected vulnerability is exceptionally high and where the behavior of the system can be precisely specified. In onchain financial infrastructure, this typically includes core financial calculation logic such as interest rate models and liquidation mechanisms, cryptographic primitives and ZKP circuit implementations, token supply and balance invariants, and access control and upgrade mechanisms. For financial institutions deploying onchain infrastructure that manages significant digital assets, formal verification of these critical components is a meaningful investment in long-term security assurance.
For financial institutions, the decision to deploy capital onchain requires confidence that the underlying systems behave correctly under all conditions, not just the conditions that have been tested. Formal verification provides documented, mathematically grounded evidence that critical system properties hold universally, which can support internal risk assessment processes, regulatory due diligence, and stakeholder communication. As onchain financial infrastructure matures and institutional adoption grows, formal verification is increasingly recognized as a component of institutional-grade security standards for high-value systems.
Zero knowledge proof systems are particularly well-suited to formal verification because their security depends on precise mathematical properties of the circuits and verification logic that underpin them. Errors in ZKP circuit implementations can allow invalid proofs to be accepted as valid, a class of vulnerability that is difficult to detect through conventional testing or code review but can be addressed through formal analysis of the circuit's mathematical properties. For organizations deploying ZKP-based infrastructure, formal verification of critical circuit components provides an additional layer of assurance beyond what standard audit techniques can offer.
OpenZeppelin's security researchers bring specialized expertise in formal verification techniques, applying them to the most critical components of the onchain systems they assess. This includes the formal analysis of smart contract invariants, ZKP circuit properties, and cryptographic implementations where mathematical proof provides assurance beyond what manual review and testing can achieve. Formal verification at OpenZeppelin is not applied in isolation, it is integrated into a broader, lifecycle-based security approach that combines audit, testing, and ongoing monitoring to provide comprehensive protection for onchain financial infrastructure.
Formal verification of onchain systems requires a rare combination of expertise: deep knowledge of smart contract security, advanced mathematical and cryptographic capability, and a precise understanding of the financial logic being verified. OpenZeppelin's team brings together PhD-level expertise in mathematics and cryptography with hands-on experience auditing the most complex and widely used protocols in the blockchain ecosystem. This combination makes OpenZeppelin uniquely equipped to apply formal verification effectively to the onchain financial infrastructure that institutions and crypto-native projects are building, and to interpret its results in the context of the broader security picture.

Penetration Testing

Penetration testing, often called pen testing, is a controlled security exercise in which experienced researchers simulate real-world attacks against a system to identify exploitable vulnerabilities before malicious actors can find them. Unlike passive security reviews, penetration testing actively probes applications, APIs, backends, and network infrastructure under conditions that closely replicate genuine attack scenarios.
Onchain financial infrastructure is a high-value target. Financial institutions and blockchain protocols must contend with sophisticated, well-resourced attackers who continuously probe for weaknesses across every layer of a system. Penetration testing provides a proactive, adversarial assessment of security posture, surfacing exploitable weaknesses in real-world conditions before they can be leveraged against production systems. For organizations managing digital assets, it is a critical component of institutional-grade risk management.
A security audit is a comprehensive review of a system's code, architecture, and logic, focused on identifying vulnerabilities through manual inspection and analysis. Penetration testing takes a more adversarial approach, actively attempting to exploit weaknesses across applications, APIs, backends, and networks to determine what a real attacker could achieve. The two are complementary: audits provide depth at the code level, while penetration testing validates security posture under real-world attack conditions. Organizations with mature security programs typically employ both.
OpenZeppelin's penetration testing engagements target the full range of systems that support onchain financial infrastructure, including web and mobile applications, APIs, backend services, and network infrastructure. This full-stack approach ensures that exploitable weaknesses are identified across every layer of a system, not just the onchain components.
Following a penetration testing engagement, OpenZeppelin provides a prioritized remediation roadmap with actionable steps to harden a client's security posture. Findings are organized by severity and exploitability, giving security and engineering teams a clear, structured path to addressing the most critical risks first.
Regulatory frameworks governing financial institutions increasingly require evidence of proactive security assessment, including adversarial testing of critical systems. Penetration testing provides documented evidence that an organization has stress-tested its infrastructure against real-world attack conditions, supporting compliance obligations and demonstrating a credible, risk-based approach to security governance.
The appropriate frequency depends on the pace of development and the risk profile of the systems involved. As a general principle, penetration testing should be conducted before major deployments, following significant infrastructure changes, and on a regular cadence as part of an ongoing security program. For financial institutions operating onchain, where frequent updates and evolving threat landscapes are the norm, regular testing is an essential component of responsible risk management.

OpenZeppelin brings a depth of blockchain-specific expertise that general penetration testing firms cannot match. Its security researchers combine hands-on knowledge of onchain systems, smart contract architecture, and blockchain infrastructure with proven adversarial testing methodologies. This makes OpenZeppelin uniquely positioned to identify the attack vectors most relevant to financial institutions and crypto-native projects operating in the blockchain ecosystem, and to provide remediation guidance that is practical, prioritized, and aligned with the specific demands of onchain financial infrastructure.

Incident Response

Incident response refers to the structured process of detecting, containing, and recovering from a security event affecting onchain systems. In the context of blockchain protocols and onchain financial infrastructure, incidents can include smart contract exploits, private key compromises, governance attacks, and vulnerabilities in offchain infrastructure. Because onchain transactions are typically irreversible, effective incident response requires both advance preparation and the ability to act decisively within a very narrow window once an event is detected.
Traditional cybersecurity incident response often benefits from the ability to reverse or contain damage after the fact, freezing accounts, rolling back transactions, or restoring systems from backup. Onchain systems offer far fewer of these options. Once assets have been moved by an attacker, recovery through technical means is rarely possible. This fundamentally changes the calculus of incident response onchain: speed of detection and containment is paramount, and the emphasis shifts toward minimizing the window between exploit and response rather than recovering lost assets after the fact.
An effective onchain incident response typically moves through four phases. Detection involves identifying that an incident is occurring or has occurred, through monitoring systems, community reports, or anomaly alerts. Containment involves taking immediate action to limit further damage, which may include pausing vulnerable contracts, rotating compromised keys, or coordinating with exchanges and bridges to flag or freeze stolen assets. Remediation involves identifying the root cause of the incident, developing and deploying a fix, and restoring normal operations. Post-incident review involves a thorough analysis of what occurred, how it was handled, and what changes are needed to prevent recurrence and improve future response.
Organizations operating onchain should ensure that a set of predefined emergency actions can be executed rapidly when an incident occurs. These typically include the ability to pause contract operations to halt ongoing exploits, rotate or revoke compromised administrative keys, execute emergency contract upgrades where upgrade mechanisms are in place, and communicate rapidly with relevant external parties including exchanges, bridges, and security partners. The effectiveness of these actions depends on them being designed, tested, and documented in advance. Under the pressure of an active incident is not the time to discover that an emergency pause mechanism was not properly implemented.
Continuous onchain monitoring is the foundation of rapid incident detection. Automated monitoring systems that track contract events, asset movements, and transaction patterns in real time can identify anomalous activity within seconds of an exploit beginning, providing the earliest possible warning and maximizing the time available for containment. Without real-time monitoring, organizations may not learn of an incident until significant damage has already occurred, through community reports or public disclosure by the attacker. Integrating monitoring with automated alerting and predefined response playbooks significantly reduces mean time to response.
OpenZeppelin provides incident response support to organizations facing active security events affecting their onchain systems. Drawing on deep expertise in smart contract security, blockchain infrastructure, and the attack vectors most commonly exploited in the ecosystem, OpenZeppelin's security researchers can rapidly assess the scope and nature of an incident, identify the root cause vulnerability, and provide guidance on containment and remediation. OpenZeppelin's familiarity with the systems of its long-term audit clients means it can provide faster and more targeted support to organizations it has worked with previously.
OpenZeppelin provides the operational tooling that organizations need to detect and respond to onchain incidents in real time. OpenZeppelin Monitor enables teams to configure automated alerts for anomalous contract behavior, unusual asset movements, and other indicators of a potential security event. OpenZeppelin Relayer provides secure, reliable transaction management that can be used to execute emergency actions, such as pausing contracts or triggering protective mechanisms, rapidly and with confidence under the pressure of an active incident. As part of the Support pillar, OpenZeppelin also delivers a Custom Monitoring Solution tailored to an organization's systems. Together these reduce the gap between detection and containment that is critical in an onchain security event.
For financial institutions operating onchain, an incident response capability is a core component of institutional-grade risk management. The irreversibility of onchain transactions means that the cost of an unprepared response is measured in assets that cannot be recovered. Establishing response procedures, testing emergency mechanisms, maintaining relationships with external security partners, and integrating real-time monitoring into operational infrastructure before an incident occurs is what separates organizations that contain damage quickly from those that do not. OpenZeppelin's combination of audit expertise, operational tooling, and incident response experience makes it a trusted partner for institutions building this capability.

Vulnerability Disclosure & Bug Bounties

Vulnerability disclosure is the process by which a security researcher who has identified a flaw in a smart contract, protocol, or onchain system reports it to the responsible organization so it can be remediated before being exploited. Responsible disclosure practices, where researchers notify the affected organization privately and allow time for a fix before any public announcement, are a cornerstone of security culture in the blockchain ecosystem. They protect users and assets while enabling developers to address vulnerabilities in an orderly way.
Responsible disclosure, sometimes called coordinated disclosure, involves a researcher reporting a vulnerability privately to the affected organization and agreeing on a timeline for remediation before any public announcement. Full disclosure involves publishing details of a vulnerability immediately or without prior notification to the affected organization. Responsible disclosure is the widely preferred standard in the blockchain security community, as it gives developers the opportunity to protect users before a vulnerability becomes publicly known and potentially exploitable by malicious actors.
A zero-day vulnerability is a security flaw that is unknown to the organization responsible for the affected system and for which no patch or mitigation exists at the time of discovery. Zero-day vulnerabilities are particularly serious because they can be exploited before any defensive action can be taken. In the blockchain ecosystem, zero-day discoveries in widely used smart contract libraries or infrastructure can put significant value at risk across many protocols simultaneously. OpenZeppelin has identified five zero-day vulnerabilities in the ecosystem, helping protect $15 billion in funds at risk across affected protocols.
A bug bounty program is a formal initiative through which an organization invites security researchers to identify and report vulnerabilities in its systems in exchange for financial rewards. Bug bounty programs provide a structured, incentive-aligned mechanism for organizations to benefit from the skills of the broader security research community, supplementing internal security measures and formal audit engagements. For blockchain protocols and financial institutions operating onchain, bug bounty programs are an important component of a layered security strategy.
Bug bounty rewards are typically tiered based on the severity and potential impact of the reported vulnerability. A common framework classifies vulnerabilities as critical, high, medium, or low severity, with reward amounts scaled accordingly. Critical vulnerabilities, those that could result in significant loss of funds, unauthorized access, or denial of service, typically command the highest rewards. Most programs also define specific areas of interest and out-of-scope items to focus researcher attention on the systems and risk categories most relevant to the organization.
Blockchain bug bounty programs typically prioritize vulnerabilities that could result in direct financial harm or loss of user trust. Common priority areas include loss of funds through theft or freezing of assets, bypassing of access controls or privilege escalation, denial of service rendering a smart contract unable to operate, and smart contract behavior that deviates from its intended specification. These categories reflect the areas where vulnerabilities in onchain systems have the most immediate and consequential impact.
Security audits and bug bounty programs serve complementary roles in a comprehensive security strategy. An audit provides a structured, time-bounded review of a system's code and architecture by an expert team before deployment, identifying vulnerabilities before they can be exploited in production. A bug bounty program provides ongoing, community-driven security research after deployment, incentivizing researchers to find vulnerabilities that may have been missed during the audit or introduced through subsequent updates. Together, they provide layered coverage across the pre-deployment and post-deployment phases of the security lifecycle.
A bug bounty program is most effective when launched after a system has already undergone a thorough security audit. Launching a program on unaudited code can result in researchers identifying large numbers of known or easily detectable vulnerabilities, diluting the program's focus and reward budget. Once a system has been audited and deployed, a bug bounty program serves as a continuous, incentive-driven layer of scrutiny that keeps pace with the evolving threat landscape and any changes made to the system over time.
OpenZeppelin takes a proactive approach to the security of its own open-source smart contract library, recognizing that vulnerabilities in a foundational library can have cascading effects across the many protocols and applications built on top of it. OpenZeppelin operates a formal bug bounty program that rewards researchers for identifying vulnerabilities in the Contracts library, with reward tiers scaled to the severity and potential impact of reported findings. OpenZeppelin also maintains a Smart Contract Security Registry, through which projects using OpenZeppelin Contracts can be alerted to vulnerabilities before public disclosure, enabling them to take protective action in advance.
The Smart Contract Security Registry is an OpenZeppelin initiative that allows projects with value locked in OpenZeppelin Contracts to receive early notification of vulnerabilities before they are publicly disclosed. By registering, projects can act on security information in advance of any public announcement, providing a meaningful window to implement mitigations and protect their users. The registry reflects OpenZeppelin's commitment to the security of the broader ecosystem, not just its direct clients.
OpenZeppelin's security researchers are active contributors to vulnerability discovery across the blockchain ecosystem. Through audit engagements, ongoing research, and participation in the broader security community, OpenZeppelin's team identifies and responsibly discloses vulnerabilities in widely used protocols and infrastructure. This includes the discovery of five zero-day vulnerabilities that collectively put $15 billion in funds at risk, demonstrating the real-world impact of OpenZeppelin's research-driven approach to security.
For organizations building onchain financial infrastructure, designing an effective bug bounty program requires careful thinking about scope, reward structure, triage processes, and integration with the broader security lifecycle. OpenZeppelin's security expertise and deep familiarity with the onchain threat landscape makes it well-positioned to support organizations in structuring programs that attract meaningful research, focus attention on the highest-risk areas, and complement existing audit and monitoring capabilities. A well-designed bug bounty program, integrated into a lifecycle-based security approach, is a meaningful signal of an organization's commitment to institutional-grade security.

This page is general information about OpenZeppelin, onchain security, and onchain financial system. For educational purposes only, not financial, investment, legal, tax, or regulatory advice. Consult your own qualified advisors before making decisions.