OpenZeppelin Contracts is a library for secure smart contract development.

OpenZeppelin

Docs NPM Package Coverage Status

A library for secure smart contract development. Build on a solid foundation of community-vetted code.

πŸ§™ Not sure how to get started? Check out Contracts Wizard β€” an interactive smart contract generator.

Overview

Installation

$ npm install @openzeppelin/contracts

OpenZeppelin Contracts features a stable API, which means your contracts won't break unexpectedly when upgrading to a newer minor version.

Usage

Once installed, you can use the contracts in the library by importing them:

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract MyCollectible is ERC721 {
    constructor() ERC721("MyCollectible", "MCO") {
    }
}

If you're new to smart contract development, head to Developing Smart Contracts to learn about creating a new project and compiling your contracts.

To keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don't need to worry about it needlessly increasing gas costs.

Learn More

The guides in the docs site will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:

  • Access Control: decide who can perform each of the actions on your system.
  • Tokens: create tradeable assets or collectives, and distribute them via Crowdsales.
  • Gas Station Network: let your users interact with your contracts without having to pay for gas themselves.
  • Utilities: generic useful tools, including non-overflowing math, signature verification, and trustless paying systems.

The full API is also thoroughly documented, and serves as a great reference when developing your smart contract application. You can also ask for help or follow Contracts's development in the community forum.

Finally, you may want to take a look at the guides on our blog, which cover several common use cases and good practices.. The following articles provide great background reading, though please note, some of the referenced tools have changed as the tooling in the ecosystem continues to rapidly evolve.

Security

This project is maintained by OpenZeppelin, and developed following our high standards for code quality and security. OpenZeppelin Contracts is meant to provide tested and community-audited code, but please use common sense when doing anything that deals with real money! We take no responsibility for your implementation decisions and any security problems you might experience.

The core development principles and strategies that OpenZeppelin Contracts 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 latest audit was done on October 2018 on version 2.0.0.

We have a bug bounty program on Immunefi. Please report any security issues you find through the Immunefi dashboard, or reach out to [email protected].

Critical bug fixes will be backported to past major releases.

Contribute

OpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the contribution guide!

License

OpenZeppelin Contracts is released under the MIT License.

Owner
OpenZeppelin
The standard for secure blockchain applications
OpenZeppelin
Comments
  • Support EIP-2309: ERC-721 Consecutive Transfer Extension

    Support EIP-2309: ERC-721 Consecutive Transfer Extension

    🧐 Motivation Support EIP-2309: ERC-721 Consecutive Transfer Extension Enables minting any number of tokens in a single transaction

    πŸ“ Details

    EIP is an extension to ERC-721, for a standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2309.md

    EIP is final status.

    Creating issue for discussion on how EIP could be supported

  • Add Create2 library

    Add Create2 library

    Fixes #1644

    This PR adds a simple CREATE2Factory based on different implementations I saw around. The goal is to have the minimum and necessary contract factory to deploy contracts using CREATE2 evm opcode. This I why I didnt added any extra methods to deploy smart contracts with a fixed bytecode, nevertheless this contract can be extended into metatxs or ownable create2 factories.

  • Add ERC165Query library

    Add ERC165Query library

    πŸš€ Description

    The ERC165 spec contains useful code for calling the supportsInterface function on an unknown contract. I use this code and I expect many others need to use this as well. It would be helpful to have it available in OpenZeppelin.

    I have added the example code from the spec to OpenZeppelin.

    Modifications:

    • changed to a library instead of contract
    • changed constant function to view function
    • added natspec comments
    • formatted to fix all linter issues

    Notes:

    • would you want unit tests for this?
    • would you want me to update the pragma for newer solidity version?
    • the security/no-inline-assembly warning can't be addressed as the spec uses inline assembly
    • [x] πŸ“˜ I've reviewed the OpenZeppelin Contributor Guidelines
    • [x] βœ… I've added tests where applicable to test my new functionality.
    • [x] πŸ“– I've made sure that my contracts are well-documented.
    • [x] 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

    Fixes #1145

  • ERC721 full implementation

    ERC721 full implementation

    Fixes #640 Fixes #809

    Continues the work of @facuspagnuolo in #682

    Current status:

    • ERC721 implementation is complete

    Pending discussions:

    • exists was added to the interface here, though will not be part of the standard
    • The 50K gas stipend for the onERC721Received call was removed (see here)
  • What is the alternative for Claimable in v2.0.0?

    What is the alternative for Claimable in v2.0.0?

    Not exactly a bug, for for those who have been using Claimable in earlier versions of OZ (for the purpose of transferOwnership followed by claimOwnership) - what are the options in v2.0.0?

    Relying solely on Ownable.transferOwnership lacks a safety mechanism for accidentally transferring the ownership to an incorrect address.

    At present, the only alternative that I see is copying Claimable.sol from v.12.0 to my repo, fixing the import "./Ownable.sol" statement, and inheriting my contracts from Claimable instead of Ownable.

    This is far from being a clean solution.

    Are there any alternatives?

    I've been reading something about roles (issue 1274, issue 1146, issue 1291).

    Is that possibly related?

    Thanks

  • ERC1155: Add a simple catch-all implementation of the metadata URI interface

    ERC1155: Add a simple catch-all implementation of the metadata URI interface

    As mentioned in https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2014#issuecomment-565499083 this is a simple implementation of the metadata URI part of ERC1155.

    I'm still a bit confused on how to do tests for OpenZeppelin (this is my first PR to the project), so I have not added tests in this PR for now. Help would be appreciated.

  • Method `decreaseApproval` in unsafe

    Method `decreaseApproval` in unsafe

    Method decreaseApproval in StandardToken.sol is unsafe. Here is the scenario.

    1. Bob is allowed to transfer zero Alice's tokens
    2. Alice allows Bob to transfer 100 of here tokens via approve or increaseApproval method and transaction is executed successfully
    3. Alice sees that Bob is now allowed to transfer 100 of her tokens
    4. After some time, Alice uses decreaseApproval method to decrease by 100 the number of her tokens Bob is allowed to transfer and transaction is executed successfully and proper Approval event was logged
    5. Alice sees that Bob is allowed to transfer 0 of her tokens
    6. Now Alice may think that once decreaseApproval call was executed successfully, then Bob didn't manage to transfer any of her tokens before the allowance was decreased, but this assumption is wrong. Actually, Bob may or may not had transferred Alice's tokens before allowance was decreased, and Alice has no easy way to know for sure whether Bob transferred her tokens or not

    Method decreaseApproval should fail in case current allowance is lower than requested decrease.

  • Virtual view functions

    Virtual view functions

    Please mark tokenURI in ERC721 virtual.

    As it's not virtual, it can't be overridden by inheriting contracts. Making this virtual would allow contracts to implement programmatic generation of token URIs without using storage slots unnecessarily.

  • Add Ownable2Step extension with 2-step transfer

    Add Ownable2Step extension with 2-step transfer

    Fixes #2369 Resolves https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1488

    This contract adds an additional layer to the trusted Ownable. The transfer is a two step process transferOwnership initiates the process and acceptOwnership makes it official.

    Transfer of ownership is a delicate and irreversible process, it could leave a contract useless, with a two step process we add a guard against typos or bad copy/paste.

    PR Checklist

    • [x] Tests
    • [ ] Documentation
    • [x] Changelog entry
  • Extend Governor with parameterized votes

    Extend Governor with parameterized votes

    This PR lays the groundwork for a future implementation of #2929, along with other potentially useful Governance extensions, by making the _castVote interface more flexible. In particular, this PR follows @frangio's suggestion and adds a data parameter to the internal, virtual _castVote method signature, along with associated countVote methods.

    The idea is this data field can be used to encode arbitrary data about the vote in question, enabling many interesting voting mechanisms via Governor extension. It can be coupled with a reporting of which kind of standardized voting mechanisms are supported in the COUNTING_MODE function.

    I'm opening this PR as draft for two reasons:

    1. To get feedback on the general approach, as suggested by @frangio and implemented here. It seems reasonable to me but I'm very open to feedback!
    2. To get suggestions on better naming. data as a parameter name and WithData for method extensions seems very generic. I think we can do better but I don't have any great ideas. One possibility would be countingContext, countingData, or something like this. Any ideas?

    PR Checklist

    • [x] Tests
    • [x] Documentation
    • [x] Changelog entry
  • Introduce an ERC-1155 _exists() function

    Introduce an ERC-1155 _exists() function

    This PR is based on a discussion started at https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2003#issuecomment-612109928 and should give the ERC-1155 implementation more compatibility to OpenZeppelin's ERC-721 implementation and also better compatibility to services like OpenSea as pointed to by https://twitter.com/xanderatallah/status/1232124941425881089

    The main thing introduced here is an _exists() function that is checked in a few places where we'd otherwise return a null-ish default value (0 or ''), and to know if a token ID is valid, it has to be registered internally first - either via minting a first token on that ID, or by calling an explicit function.

    Tests will fail on this PR for the moment as it bases on both #2130 and #2029 - also, I have not written any tests for this PR itself yet as it's mostly a suggestion on how we could do this in a good way.

  • Draft: timestamp based governor with EIP-5805

    Draft: timestamp based governor with EIP-5805

    Fixes #3081

    WIP

    This includes a lot of retypes that should be safe, but that must be double-checked, and that the plugin needs to understand.

    This requires a lot more tests, including tests of backward compatibility with tokens that don't expose a clock() function.

    PR Checklist

    • [ ] Tests
    • [ ] Documentation
    • [ ] Changelog entry
  • Disallow Address Poisoning in ERC20

    Disallow Address Poisoning in ERC20

    πŸ’» Environment

    Environment is not applicable to this bug report as it pertains to the smart contracts themselves and how they behave on-chain.

    πŸ“ Details

    The current token contract implementation of the EIP-20 standard does not satisfy all SHOULD clauses of the standard definition and as such permits the commonly-known address poisoning attack by executing transferFrom instructions from arbitrary addresses with an amount of 0.

    The problem arises from how _spendAllowance evaluates the approval between the caller and the sender of the funds. In the EIP-20 standard, the following statement is present:

    The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism

    This condition is not validated for zero-value transfers as no "deliberate" approval is evaluated. To ensure we remain compliant with the EIP-20 standard in full, we cannot disallow zero-value transfers altogether.

    As a workaround, we propose that the require check within _spendAllowance is refactored to evaluate a non-zero approval between the sender of funds and the caller.

    This change will ensure maximal compatibility with existing contract systems, conform to the EIP-20 standard to a greater degree, and address the address poisoning attack we have seen being extensively exploited in recent times.

    πŸ”’ Code to reproduce bug

    A simple Solidity smart contract to illustrate the bug in action:

    import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
    
    contract Poisoning {
        ERC20 public immutable token;
    
        constructor() {
            token = new ERC20("Test", "TST");
        }
    
        function poison(address from_, address to_) external {
            require(token.allowance(from_, address(this)) == 0);
            token.transferFrom(from_, to_, 0);
        }
    }
    

    Invoking the poison function with arbitrary from_ and to_ arguments will successfully perform a transferFrom invocation even when the approval between from_ (the sender of funds) and address(this) (the caller of the transferFrom function) has been set to 0.

    This behaviour permits polluting the transfer history of an account on blockchain explorers which in turn can cause users to be misled and copy incorrect addresses when performing their own valid transfers.

  • Prepare tests for hardhat-exposed transition

    Prepare tests for hardhat-exposed transition

    #3816 included a change to ERC721VotesMock.sol, adding a dummy argument to match ERC20Votes burn function.

    This causes issues when removing the mocks in favor of the hardhat-exposed plugin.

    This PR removes this dummy parameter, and gives the Votes.behavior.js the ability to detect the burn function signature, and to adapt the arguments accordingly

    PR Checklist

    • [x] Tests
  • Consider removing Context

    Consider removing Context

    Context provides _msgSender() and the reason it exists and is used across the codebase is so that the logic for getting the function caller can be replaced via inheritance, for example using ERC2771Context. It is necessary if we want to support overriding that logic for any piece of code in the library. While Context is fairly simple, it is pervasive and the vast majority of use cases do not need the functionality at all, so it's a great candidate for removal to simplify the code.

    We would like to understand first if Context alternatives such as ERC2771Context are actively used, as well as what are the alternative recommendations we can make for those use cases.

  • Include address(this) when computing Governor proposal ids

    Include address(this) when computing Governor proposal ids

    From https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2961.

    Governor proposal ids are hashes of the proposal parameters, but they are currently not scoped to the governor contract itself. This issue is about scoping them by including address(this) in the hash.

Troon-NFT-Contract is deployed on Flow Blockchain, which is a white-label smart-contract for NFTs with an addition layer of Brand, Schema and Template

Overview Summary of NFTContract NFTContract is a Non Fungible Token (NFT) standard for Flow blockchain. It offers a powerful set while keeping unneces

Jan 4, 2022
DERO: Secure, Anonymous Blockchain with Smart Contracts. Subscribe to Dero announcements by sending mail to [email protected] with subject: subscribe announcements
DERO: Secure, Anonymous Blockchain with Smart Contracts.  Subscribe to Dero announcements by sending mail to lists@dero.io with subject: subscribe announcements

Welcome to the Dero Project DERO News Forum Wiki Explorer Source Twitter Discord Github Stats WebWallet Medium Table of Contents ABOUT DERO PROJECT DE

Dec 7, 2022
Akroma GO client - Akroma is an EVM based application development platform (smart-contracts).

Akroma Akroma is an EVM based application development platform (smart-contracts). Akroma will utilize a Masternode system, and build out an Oracle pla

Dec 11, 2022
A smart contract development toolchain for Go

ethgen - A smart contract development toolchain for Go A simple yet powerful toolchain for Go based smart contract development Compile solidity contra

Sep 14, 2022
Arbitrum is a Layer 2 cryptocurrency platform that makes smart contracts scalable, fast, and private.
Arbitrum is a Layer 2 cryptocurrency platform that makes smart contracts scalable, fast, and private.

Arbitrum is a Layer 2 cryptocurrency platform that makes smart contracts scalable, fast, and private. Arbitrum interoperates closely with Ethereum, so Ethereum developers can easily cross-compile their contracts to run on Arbitrum. Arbitrum achieves these goals through a unique combination of incentives, network protocol design, and virtual machine architecture.

Jan 8, 2023
Tools to help teams develop smart contracts on the Cardano blockchain
Tools to help teams develop smart contracts on the Cardano blockchain

toolkit-for-cardano toolkit-for-cardano simplifies the development of Cardano smart contracts by providing teams with frequently needed tasks: Build T

Dec 19, 2022
Accompanying repository for the "Build Ethereum From Scratch - Smart Contracts and More" course by David Katz
Accompanying repository for the

Build Ethereum From Scratch - Smart Contracts and More This repository accompanies the "Build Ethereum From Scratch - Smart Contracts and More" course

Dec 7, 2022
An interoperable smart contract hub
An interoperable smart contract hub

Juno An interoperable smart contract hub which automatically executes, controls or documents a procedure of relevant events and actions according to t

Jan 1, 2023
A Gomora template for building dApps and web3-powered API and smart contract listeners

Gomora dApp A Gomora template for building dApps and web3-powered API and smart contract listeners Local Development Setup the .env file first cp .env

Feb 15, 2022
A guide to smart contract security best practices

Smart Contract Security Best Practices Visit the documentation site: https://consensys.github.io/smart-contract-best-practices/ Read the docs in Chine

Dec 27, 2022
An open source smart contract platform

EOSIO - The Most Powerful Infrastructure for Decentralized Applications Welcome to the EOSIO source code repository! This software enables businesses

Jan 7, 2023
The Fabric Smart Client is a new Fabric Client that lets you focus on the business processes and simplifies the development of Fabric-based distributed application.

Fabric Smart Client The Fabric Smart Client (FSC, for short) is a new Fabric client-side component whose objective is twofold. FSC aims to simplify th

Dec 14, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Jan 9, 2023
Contracts for the versus-flow.art project

Versus Flow Auction Contract This is a git repo for the cadence contrats for versus@flow. Follow the guide below to set it up and test locally in the

Jul 19, 2022
C4udit - Static analyzer for solidity contracts based on regexs specifically crafted for Code4Rena contests

c4udit Introduction c4udit is a static analyzer for solidity contracts based on

Jan 9, 2023
Return list of the contract's events logs

Return list of the contract's events logs Return contract's events logs via sending address, from_block and to_block range only as RAW data. Working w

Oct 12, 2021
Abigen by contract address using etherscan api

Abigen for zoomers Just a simple wrapper to fetch abis from etherscan and run abigen on it. Uses the name of a contract if possible. Usage First put y

Mar 24, 2022
Smart.go is a pure Golang library to access disk low-level S.M.A.R.T. information

Smart.go is a pure Golang library to access disk low-level S.M.A.R.T. information. Smart.go tries to match functionality provided by smartctl but with golang API.

Dec 27, 2022
The bare metal Go smart card
The bare metal Go smart card

Authors Andrea Barisani [email protected] | [email protected] Introduction The GoKey application implements a USB smartcard in pure Go

Dec 8, 2022