OpenZeppelin is a “battle-tested” open source framework comprised of reusable Ethereum smart contracts. The framework helps smart contract developers reduce the risk of vulnerabilities in their distributed applications (dapps) by using standard, tested, community-reviewed code. Today, its smart contracts power over $4.5 billion worth of digital assets. We recently shared lessons learned from contributing to the project.
The core development principles and strategies that OpenZeppelin is based on include: security in depth, simple and modular code, clarity-driven naming conventions, comprehensive unit testing, pre-and-post-condition sanity checks, code consistency, and regular audits.
The following provides visibility into how OpenZeppelin’s smart contracts are organized:
access — Smart contracts that enable functionality that can be used for selective restrictions and basic authorization control functions. Includes address whitelisting and signature-based permissions management.
crowdsale — A collection of smart contracts used to manage token crowdsales that allow investors to purchase tokens with ETH. Includes a base contract which implements fundamental crowdsale functionality in its simplest form. The base contract can be extended in order to satisfy your crowdsale’s specific requirements.
- distribution — Includes extensions of the base crowdsale contract which can be used to customize the completion of a crowdsale.
- emission — Includes extensions of the base crowdsale contract which can be used to mint and manage how tokens are issued to purchasers.
- price — Includes extensions of the crowdsale contract that can be used to manage changes in token prices.
- validation — Includes extensions of the crowdsale contract that can be used to enforce restraints and limit access to token purchases.
examples — A collection of simple smart contracts that demonstrate how to add new features to base contracts through multiple inheritance.
introspection — An interface that can be used to make a contract comply with the ERC-165 standard as well as a contract that implements ERC-165 using a lookup table.
lifecycle — A collection of base contracts used to manage the existence and behavior of your contracts and their funds.
math — Libraries with safety checks on operations that throw on errors.
mocks — A collection of abstract contracts that are primarily used for unit testing. They also serve as good usage examples and demonstrate how to combine contracts with inheritence when developing your own custom applciations.
ownership — A collection of smart contracts that can be used to manage contract and token ownership
- rbac — A library used to manage addresses assigned to different user roles and an example Role-Based Access Control (RBAC) interface that demonstrates how to handle setters and getters for roles and addresses.
payment — A collection of smart contracts that can be used to manage payments through escrow arrangements, withdrawals, and claims. Includes support for both single payees and multiple payees.
proposals — A collection of smart contracts that reflect community Ethereum Improvement Proposals (EIPs). These contracts are under development and standardization. They are not recommended for production, but they are useful for experimentation with pending EIP standards. Go here for more information.
token — A collection of approved ERC standard tokens — their interfaces and implementations.
- ERC20 — A standard interface for fungible tokens:
- Interfaces — Includes the ERC-20 token standard basic interface. I.e., what the contract’s ABI can represent.
- Implementations — Includes ERC-20 token implementations that include all required and some optional ERC-20 functionality.
- ERC721 — A standard interface for non-fungible tokens
- Interfaces — Includes the ERC-721 token standard basic interface. I.e., what the contract’s ABI can represent.
- Implementations — Includes ERC-721 token implementations that include all required and some optional ERC-721 functionality.
How To Use OpenZeppelin’s Contracts
When using OpenZeppelin to build your own distributed applications, for security reasons you should NOT modify the framework’s base contracts, libraries, and interfaces. In order to leverage and extend their functionality, you’re encouraged to inherit from them or combine them with your own contracts.
The Solidity programming language supports multiple inheritance. This is very powerful yet it can also be confusing: the more complexity you introduce to your distributed applications through multiple inheritance, the greater your application’s attack surface is.
You’ll notice in the
/mocks directory there are a collection of abstract contracts used for testing that can also be used as the foundation for your own custom implementations. These mock contracts demonstrate how OpenZeppelin’s secure base contracts can be used with multiple inheritance.
To learn more about combining OpenZeppelin contracts with your own custom contracts we encourage you to read the following: On crowdsales and multiple inheritance. There’s a great example in the article that walks through how to extend OpenZeppelin’s base
Crowdsale.sol contract with their
CappedCrowdsale.sol contracts using multiple inheritance.
- OpenZeppelin provides developers and teams with the building blocks necessary to build the next generation of blockchain-based smart contracts.
- The core development principles include: security in depth, simple and modular code, clarity-driven naming conventions, comprehensive unit testing, pre-and-post-condition sanity checks, code consistency, and regular audits.
- OpenZeppelin’s architecture provides a coherent way to organize different base contracts, libraries, and interfaces that can be extended and used for your own custom implementations.
- You should NOT modify the OpenZeppelin’s base contracts, libraries, and interfaces.
- In order to extend OpenZeppelin’s base contracts, libraries, and interfaces, you’re encouraged to inherit from them (Solidity supports multiple inheritance) or combine them with your own contracts.
- Multiple inheritance is very powerful, but it can increase your application’s attack service. It’s important to be very deliberate when using it.