Skip to content

OpenZeppelin

OpenZeppelin Contracts provides Solidity components for tokens, permissions, governance and proxies. Reuse requires reviewing versions, configuration, composition and storage compatibility during upgrades. Teams specify which roles control each function and test the final composition, including external interactions. Reusing a reviewed component does not establish that a custom contract has been audited.

Written by Isaac GonzálezUpdated October 11, 2026

Key takeaways

  • OpenZeppelin Contracts provides reusable Solidity components.
  • Versions, permissions and composition still need review.
  • Upgrades require initializer, authorisation and storage checks.

What is OpenZeppelin?

OpenZeppelin Contracts is a library of Solidity components for token standards, permissions, governance and other patterns. It supports reuse of documented implementations rather than writing every primitive from scratch. The OpenZeppelin company and its services are distinct from the scope of the open-source library.

Using it helps focus review on composition, configuration and custom logic. It does not mean the resulting contract has been audited or that all versions have identical properties. The specific release and relevant security advisories belong in the project's dependency inventory.

How it works

Components are imported and combined through Solidity mechanisms. Each extension adds rules and interactions that need understanding: pausing, issuance permissions and transfer authorisations are different capabilities. Teams define who administers each function and how those powers are transferred or revoked.

Proxy deployments use adapted contracts and upgrade tools. Initializers, upgrade authorisation and storage compatibility require review. An update changing the state layout without respecting its constraints can damage a deployment even when the new code compiles successfully and basic tests pass.

What OpenZeppelin offers

A token can combine controlled issuance, pausing and differentiated permissions. Tests should check permitted actions, attempts by users without roles and administrator changes. Overrides of standard functions also need review for unexpected behaviour affecting wallets or other integrating contracts.

Upgrade processes retain the previous implementation, compare storage and simulate operations against representative state. Delivery documentation identifies who can execute the change and the checks performed afterwards. Timelocks and multisigs introduce administration rules that also require configuration, testing and ongoing maintenance by the responsible team.

Limitations and selection criteria

Inheriting library contracts does not resolve every economic rule or product obligation. ERC-3643, for example, has a reference implementation distributed separately from OpenZeppelin Contracts. Combining compatible components does not independently establish that an issuance meets its applicable requirements.

The MIT licence permits commercial use under its conditions, including preservation of applicable notices. Maintenance pins versions, reviews incompatible changes and checks each update's impact. Audits and tests should be described by scope rather than treating a familiar dependency as a guarantee of invulnerability for the resulting application.

Also known as

  • OZ
  • OpenZeppelin Contracts
  • @openzeppelin/contracts
Development at Metlabs

How we approach a project with OpenZeppelin

Development capabilities and use cases to assess how OpenZeppelin fits your product.

What we build with OpenZeppelin at Metlabs

  • Standard tokens

    Standard implementations with pinned versions and review of extensions and permissions.

  • Access control

    Granular roles, multi-sig and timelock for governance and critical operations.

  • Contract upgrades

    Proxies and migrations with authorisation, initialization and storage compatibility checks.

  • Use case

    ERC-20 contract with governance

    Utility token with AccessControl, Pausable and upgradeable proxy, all on the OpenZeppelin base.

Related content

Go deeper on OpenZeppelin

Other Metlabs pages that expand on this entry.

FAQ's

Frequently asked questions

No. Reviews of published components do not automatically cover extensions or product-specific logic. Evidence of an audit of the final contract requires a report, an identified version and a scope covering the composition and configuration actually deployed, alongside the tests performed by the implementation team.

Building with OpenZeppelin?

We analyze your case, pick the right stack and ship a production-ready solution.

Tell us about your project

As featured in

CointelegraphInvesting.comEl EspañolEmprendedoresEl ObservadorCriptoNoticias