OpenZeppelin Contracts is a library for secure smart contract development.

Overview

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.

Issues
  • 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.

    feature contracts 
    opened by AugustoL 42
  • 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

    feature contracts 
    opened by ldub 34
  • 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)
    opened by spalladino 34
  • 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.

    opened by KaiRo-at 32
  • 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.

    opened by 3sGgpQ8H 32
  • 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.

    feature 
    opened by Arachnid 31
  • 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
    opened by apbendi 29
  • 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.

    stale 
    opened by KaiRo-at 29
  • Add ERC1155URIStorage

    Add ERC1155URIStorage

    Fixes #3206

    • add a new extension for ERC1155 called ERC1155URIStorage that implements a ERC721-style _setTokenURI and tokenURI behaviors.

    PR Checklist

    • [x] Tests
    • [x] Documentation (inline)
    • [x] Changelog entry
    opened by takahser 28
  • Update contracts to support Solidity 0.8.x

    Update contracts to support Solidity 0.8.x

    Fixes #2441

    Contracts' solidity version pragmas were updated to support Solidity 0.8.x.

    Changes include:

    • Updated explicit type conversions that conform with the new restrictions.
    • Functions that rely on chainid in inline assembly are now view instead of pure.

    Important Note: Some tests are still not passing because since 0.8.0 failing assertions and other internal checks like division by zero or arithmetic overflow do not use the invalid opcode, but instead the revert opcode. And I believe that this is something worth discussing how to handle before making any changes to the current test cases.

    opened by andrekorol 28
  • Signature Malleability:

    Signature Malleability:

    If you allow both values 0/1 and 27/28, you allow two different signatures both resulting in a same valid recovery. (r,s,0/1) and (r,s,27/28) would both be valid, recover the same public key and sign the same data. Furthermore, given (r,s,0/1), (r,s,27/28) can be constructed by anyone. In my contracts, I removed line 37 to line 39.

    I further checked with geth, and in the transaction and ethapi, only 27/28 is considered. Thus, I added a function fixSignature() to convert 0/1 to 27/28 resulting from web3.eth.sign().

    The current implementation opens attacks on contracts that rely where a signature is unique. This is for example ERC 865 as implemented in this pull request.

    bug contracts 
    opened by tbocek 27
  • Fix/inheritdoc #3502

    Fix/inheritdoc #3502

    Fixes #3502

    Remove comments of type @dev See {CONTRACT-METHOD} that do not add more context. Solc will inherit the comment by default.

    PR Checklist

    • [x] Tests
    • [ ] Documentation
    • [ ] Changelog entry
    opened by GrandSchtroumpf 0
  • [natspec] Use @inheritdoc instead of

    [natspec] Use @inheritdoc instead of "See {***}"

    When compiling a contract, the devdoc doesn't extends from the parent. For example when compiling the ERC20 contract, the devdoc of method balanceOf is

    See {IERC20-balanceOf}.
    

    Instead of

    Returns the amount of tokens owned by `account`.
    

    ๐Ÿ’ป Environment Hardhat

    ๐Ÿ“ Details

    npx hardhat compile
    

    Check the build-info with the compile output : JSON.parse(output.contracts[sourceName][contractName].metadata).output.devdoc. The methods don't inherit the parent class.

    ๐Ÿ› ๏ธ Solution Use @inheritdoc <contractName> instead of See {<contractName>-<method>}. Here are two example from ERC20, with full inherited documentation & extended documentation

      /**
       * @inheritdoc IERC20
       */
       function balanceOf(...) ... {...)
       
      /**
       * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
       * `transferFrom`. This is semantically equivalent to an infinite approval.
       *
       * Requirements:
       *
       * - `spender` cannot be the zero address.
       * @inheritdoc IERC20
       */
        function approve(...) ... { ... }
    

    I can make a draft PR to discuss the implementation if you want. Thanks ๐Ÿ™‚

    opened by GrandSchtroumpf 7
  • ERC4626 Tracker should be part of release

    ERC4626 Tracker should be part of release

    As per the discussion https://forum.openzeppelin.com/t/erc4626-vault-implementation-for-totalassets-in-base-contract/29474 and https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3497#issuecomment-1162864795 , requesting "ERC4626 Tracker" contract as part of release.

    cc @Amxx

    opened by jaglinux 2
  • Support taxed tokens transfers in the ERC4626 contract

    Support taxed tokens transfers in the ERC4626 contract

    Scope ERC4626

    Motivation Make the standard more inclusive and usable across the hugely-diversified DeFi ecosystem by supporting taxed tokens transfers.

    Description Implement a token transfer library that takes into account tokens with transfer taxes or non-standard behaviours (example: a user calls deposit(...amount = 10) but the actual deposit is 9 TKN because of a 10% transfer tax.

    Example

    function transferTokens(
            IERC20 token,
            address from,
            address to,
            uint256 amount
        ) internal returns (uint256 originalBalance, uint256 received) {
            if (token.balanceOf(from) < amount) revert TransferHelper__Insufficient_Token_Balance(from, address(token));
    
            if (token.allowance(from, address(this)) < amount)
                revert TransferHelper__Insufficient_Token_Allowance(from, address(this), address(token));
    
            // computes transferred balance for tokens with tax on transfers
            originalBalance = token.balanceOf(to);
            token.safeTransferFrom(from, to, amount);
    
            received = token.balanceOf(to) - originalBalance;
        }
    

    Now instead of SafeERC20.transferFrom(...) one could use the function above using the received value instead of the user-inputted amount.

    Source: TransferHelper.sol

    opened by OxMarco 4
Releases(v4.7.0-rc.0)
  • v4.7.0-rc.0(Jun 7, 2022)

    This prerelease is now available for open review! Let us know your feedback and if you find any security issues.

    We have a bug bounty with rewards of up to USD $25,000 and a special POAP for submitting a valid issue.

    See the announcement for more details.

    Source code(tar.gz)
    Source code(zip)
  • v4.6.0(Apr 29, 2022)

    • crosschain: Add a new set of contracts for cross-chain applications. CrossChainEnabled is a base contract with instantiations for several chains and bridges, and AccessControlCrossChain is an extension of access control that allows cross-chain operation. (#3183)
    • AccessControl: add a virtual _checkRole(bytes32) function that can be overridden to alter the onlyRole modifier behavior. (#3137)
    • EnumerableMap: add new AddressToUintMap map type. (#3150)
    • EnumerableMap: add new Bytes32ToBytes32Map map type. (#3192)
    • ERC20FlashMint: support infinite allowance when paying back a flash loan. (#3226)
    • ERC20Wrapper: the decimals() function now tries to fetch the value from the underlying token instance. If that calls revert, then the default value is used. (#3259)
    • draft-ERC20Permit: replace immutable with constant for _PERMIT_TYPEHASH since the keccak256 of string literals is treated specially and the hash is evaluated at compile time. (#3196)
    • ERC1155: Add a _afterTokenTransfer hook for improved extensibility. (#3166)
    • ERC1155URIStorage: add a new extension that implements a _setURI behavior similar to ERC721's _setTokenURI. (#3210)
    • DoubleEndedQueue: a new data structure that supports efficient push and pop to both front and back, useful for FIFO and LIFO queues. (#3153)
    • Governor: improved security of onlyGovernance modifier when using an external executor contract (e.g. a timelock) that can operate without necessarily going through the governance protocol. (#3147)
    • Governor: Add a way to parameterize votes. This can be used to implement voting systems such as fractionalized voting, ERC721 based voting, or any number of other systems. The params argument added to _countVote method, and included in the newly added _getVotes method, can be used by counting and voting modules respectively for such purposes. (#3043)
    • Governor: rewording of revert reason for consistency. (#3275)
    • Governor: fix an inconsistency in data locations that could lead to invalid bytecode being produced. (#3295)
    • Governor: Implement IERC721Receiver and IERC1155Receiver to improve token custody by governors. (#3230)
    • TimelockController: Implement IERC721Receiver and IERC1155Receiver to improve token custody by timelocks. (#3230)
    • TimelockController: Add a separate canceller role for the ability to cancel. (#3165)
    • Initializable: add a reinitializer modifier that enables the initialization of new modules, added to already initialized contracts through upgradeability. (#3232)
    • Initializable: add an Initialized event that tracks initialized version numbers. (#3294)
    • ERC2981: make royaltiInfo public to allow super call in overrides. (#3305)

    Upgradeability notice

    • TimelockController: (Action needed) The upgrade from <4.6 to >=4.6 introduces a new CANCELLER_ROLE that requires set up to be assignable. After the upgrade, only addresses with this role will have the ability to cancel. Proposers will no longer be able to cancel. Assigning cancellers can be done by an admin (including the timelock itself) once the role admin is set up. To do this, we recommend upgrading to the TimelockControllerWith46MigrationUpgradeable contract and then calling the migrateTo46 function.

    Breaking changes

    • Governor: Adds internal virtual _getVotes method that must be implemented; this is a breaking change for existing concrete extensions to Governor. To fix this on an existing voting module extension, rename getVotes to _getVotes and add a bytes memory argument. (#3043)
    • Governor: Adds params parameter to internal virtual _countVote method; this is a breaking change for existing concrete extensions to Governor. To fix this on an existing counting module extension, add a bytes memory argument to _countVote. (#3043)
    • Governor: Does not emit VoteCast event when params data is non-empty; instead emits VoteCastWithParams event. To fix this on an integration that consumes the VoteCast event, also fetch/monitor VoteCastWithParams events. (#3043)
    • Votes: The internal virtual function _getVotingUnits was made view (which was accidentally missing). Any overrides should now be updated so they are view as well.
    Source code(tar.gz)
    Source code(zip)
  • v4.6.0-rc.0(Apr 1, 2022)

    This prerelease is now available for open review! Let us know your feedback and if you find any security issues.

    We have a bug bounty with rewards of up to USD $25,000 and a special POAP for submitting a valid issue.

    See the announcement for some more details.

    Source code(tar.gz)
    Source code(zip)
  • v4.5.0(Feb 9, 2022)

    • ERC2981: add implementation of the royalty standard, and the respective extensions for ERC721 and ERC1155. (#3012)
    • GovernorTimelockControl: improve the state() function to have it reflect cases where a proposal has been canceled directly on the timelock. (#2977)
    • Preset contracts are now deprecated in favor of Contracts Wizard. (#2986)
    • Governor: add a relay function to help recover assets sent to a governor that is not its own executor (e.g. when using a timelock). (#2926)
    • GovernorPreventLateQuorum: add new module to ensure a minimum voting duration is available after the quorum is reached. (#2973)
    • ERC721: improved revert reason when transferring from wrong owner. (#2975)
    • Votes: Added a base contract for vote tracking with delegation. (#2944)
    • ERC721Votes: Added an extension of ERC721 enabled with vote tracking and delegation. (#2944)
    • ERC2771Context: use immutable storage to store the forwarder address, no longer an issue since Solidity >=0.8.8 allows reading immutable variables in the constructor. (#2917)
    • Base64: add a library to parse bytes into base64 strings using encode(bytes memory) function, and provide examples to show how to use to build URL-safe tokenURIs. (#2884)
    • ERC20: reduce allowance before triggering transfer. (#3056)
    • ERC20: do not update allowance on transferFrom when allowance is type(uint256).max. (#3085)
    • ERC20: add a _spendAllowance internal function. (#3170)
    • ERC20Burnable: do not update allowance on burnFrom when allowance is type(uint256).max. (#3170)
    • ERC777: do not update allowance on transferFrom when allowance is type(uint256).max. (#3085)
    • ERC777: add a _spendAllowance internal function. (#3170)
    • SignedMath: a new signed version of the Math library with max, min, and average. (#2686)
    • SignedMath: add a abs(int256) method that returns the unsigned absolute value of a signed value. (#2984)
    • ERC1967Upgrade: Refactor the secure upgrade to use ERC1822 instead of the previous rollback mechanism. This reduces code complexity and attack surface with similar security guarantees. (#3021)
    • UUPSUpgradeable: Add ERC1822 compliance to support the updated secure upgrade mechanism. (#3021)
    • Some more functions have been made virtual to customize them via overrides. In many cases this will not imply that other functions in the contract will automatically adapt to the overridden definitions. People who wish to override should consult the source code to understand the impact and if they need to override any additional functions to achieve the desired behavior.

    Breaking changes

    • ERC1967Upgrade: The function _upgradeToAndCallSecure was renamed to _upgradeToAndCallUUPS, along with the change in security mechanism described above.
    • Address: The Solidity pragma is increased from ^0.8.0 to ^0.8.1. This is required by the account.code.length syntax that replaces inline assembly. This may require users to bump their compiler version from 0.8.0 to 0.8.1 or later. Note that other parts of the code already include stricter requirements.
    Source code(tar.gz)
    Source code(zip)
  • v4.5.0-rc.0(Jan 14, 2022)

    This prerelease is now available for review! Let us know your feedback and if you find any security issues.

    We have a bug bounty with rewards of up to USD $25,000 and a special POAP for submitting a valid issue.

    See the announcement for some more details.

    Source code(tar.gz)
    Source code(zip)
  • v4.4.2(Jan 11, 2022)

  • v4.4.1(Dec 14, 2021)

    :warning: This is a patch for a low severity vulnerability. For more information visit the security advisory.

    • Initializable: change the existing initializer modifier and add a new onlyInitializing modifier to prevent reentrancy risk. (#3006)

    Breaking change

    It is no longer possible to call an initializer-protected function from within another initializer function outside the context of a constructor. Projects using OpenZeppelin upgradeable proxies should continue to work as is, since in the common case the initializer is invoked in the constructor directly. If this is not the case for you, the suggested change is to use the new onlyInitializing modifier in the following way:

     contract A {
    -    function initialize() public   initializer { ... }
    +    function initialize() internal onlyInitializing { ... }
     }
     contract B is A {
         function initialize() public initializer {
             A.initialize();
         }
     }
    
    Source code(tar.gz)
    Source code(zip)
  • v4.4.0(Nov 25, 2021)

    Check out the first OpenZeppelin Community Call where the team discussed everything that is included in this release.

    And if you missed it, we recently announced an official bug bounty program for OpenZeppelin Contracts. Check it out!

    • Ownable: add an internal _transferOwnership(address). (#2568)
    • AccessControl: add internal _grantRole(bytes32,address) and _revokeRole(bytes32,address). (#2568)
    • AccessControl: mark _setupRole(bytes32,address) as deprecated in favor of _grantRole(bytes32,address). (#2568)
    • AccessControlEnumerable: hook into _grantRole(bytes32,address) and _revokeRole(bytes32,address). (#2946)
    • EIP712: cache address(this) to immutable storage to avoid potential issues if a vanilla contract is used in a delegatecall context. (#2852)
    • Add internal _setApprovalForAll to ERC721 and ERC1155. (#2834)
    • Governor: shift vote start and end by one block to better match Compound's GovernorBravo and prevent voting at the Governor level if the voting snapshot is not ready. (#2892)
    • GovernorCompatibilityBravo: consider quorum an inclusive rather than exclusive minimum to match Compound's GovernorBravo. (#2974)
    • GovernorSettings: a new governor module that manages voting settings updatable through governance actions. (#2904)
    • PaymentSplitter: now supports ERC20 assets in addition to Ether. (#2858)
    • ECDSA: add a variant of toEthSignedMessageHash for arbitrary length message hashing. (#2865)
    • MerkleProof: add a processProof function that returns the rebuilt root hash given a leaf and a proof. (#2841)
    • VestingWallet: new contract that handles the vesting of Ether and ERC20 tokens following a customizable vesting schedule. (#2748)
    • Governor: enable receiving Ether when a Timelock contract is not used. (#2748)
    • GovernorTimelockCompound: fix ability to use Ether stored in the Timelock contract. (#2748)
    Source code(tar.gz)
    Source code(zip)
  • v4.3.3(Nov 15, 2021)

    :warning: This is a security patch. For more information visit the security advisory.

    • ERC1155Supply: Handle totalSupply changes by hooking into _beforeTokenTransfer to ensure consistency of balances and supply during IERC1155Receiver.onERC1155Received calls.
    Source code(tar.gz)
    Source code(zip)
  • v4.3.2(Sep 14, 2021)

    :warning: This is a security patch. For more information visit the security advisory.

    • UUPSUpgradeable: Add modifiers to prevent upgradeTo and upgradeToAndCall being executed on any contract that is not the active ERC1967 proxy. This prevents these functions being called on implementation contracts or minimal ERC1167 clones, in particular.
    Source code(tar.gz)
    Source code(zip)
  • v4.3.1(Aug 26, 2021)

  • v3.4.2-solc-0.7(Aug 26, 2021)

  • v3.4.2(Aug 26, 2021)

  • v4.3.0(Aug 17, 2021)

    Visit our blog for the full 4.3 announcement as well as Governor announcement!

    • ERC2771Context: use private variable from storage to store the forwarder address. Fixes issues where _msgSender() was not callable from constructors. (#2754)
    • EnumerableSet: add values() functions that returns an array containing all values in a single call. (#2768)
    • Governor: added a modular system of Governor contracts based on GovernorAlpha and GovernorBravo. (#2672)
    • Add an interfaces folder containing solidity interfaces to final ERCs. (#2517)
    • ECDSA: add tryRecover functions that will not throw if the signature is invalid, and will return an error flag instead. (#2661)
    • SignatureChecker: Reduce gas usage of the isValidSignatureNow function for the "signature by EOA" case. (#2661)
    Source code(tar.gz)
    Source code(zip)
  • v4.2.0(Jun 30, 2021)

    Read the full announcement in the blog!


    • ERC20Votes: add a new extension of the ERC20 token with support for voting snapshots and delegation. (#2632)
    • ERC20VotesComp: Variant of ERC20Votes that is compatible with Compound's Comp token interface but restricts supply to uint96. (#2706)
    • ERC20Wrapper: add a new extension of the ERC20 token which wraps an underlying token. Deposit and withdraw guarantee that the total supply is backed by a corresponding amount of underlying token. (#2633)
    • Enumerables: Improve gas cost of removal in EnumerableSet and EnumerableMap.
    • Enumerables: Improve gas cost of lookup in EnumerableSet and EnumerableMap.
    • Counter: add a reset method. (#2678)
    • Tokens: Wrap definitely safe subtractions in unchecked blocks.
    • Math: Add a ceilDiv method for performing ceiling division.
    • ERC1155Supply: add a new ERC1155 extension that keeps track of the totalSupply of each tokenId. (#2593)
    • BitMaps: add a new BitMaps library that provides a storage efficient datastructure for uint256 to bool mapping with contiguous keys. (#2710)

    Breaking Changes

    • ERC20FlashMint is no longer a Draft ERC. (#2673))

    How to update: Change your import paths by removing the draft- prefix from @openzeppelin/contracts/token/ERC20/extensions/draft-ERC20FlashMint.sol.

    See Releases and Stability: Drafts.

    Source code(tar.gz)
    Source code(zip)
  • v4.1.0(Apr 30, 2021)

    Read the full announcement in the blog or check out the changelog.

    • IERC20Metadata: add a new extended interface that includes the optional name(), symbol() and decimals() functions. (#2561)
    • ERC777: make reception acquirement optional in _mint. (#2552)
    • ERC20Permit: add a _useNonce to enable further usage of ERC712 signatures. (#2565)
    • ERC20FlashMint: add an implementation of the ERC3156 extension for flash-minting ERC20 tokens. (#2543)
    • SignatureChecker: add a signature verification library that supports both EOA and ERC1271 compliant contracts as signers. (#2532)
    • Multicall: add abstract contract with multicall(bytes[] calldata data) function to bundle multiple calls together (#2608)
    • ECDSA: add support for ERC2098 short-signatures. (#2582)
    • AccessControl: add a onlyRole modifier to restrict specific function to callers bearing a specific role. (#2609)
    • StorageSlot: add a library for reading and writing primitive types to specific storage slots. (#2542)
    • UUPS Proxies: add UUPSUpgradeable to implement the UUPS proxy pattern together with EIP1967Proxy. (#2542)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Mar 24, 2021)

    Read the full announcement in the blog or check out the changelog.

    Changelog

    • Now targeting the 0.8.x line of Solidity compilers. For 0.6.x (resp 0.7.x) support, use version 3.4.0 (resp 3.4.0-solc-0.7) of OpenZeppelin.
    • Context: making _msgData return bytes calldata instead of bytes memory (#2492)
    • ERC20: removed the _setDecimals function and the storage slot associated to decimals. (#2502)
    • Strings: addition of a toHexString function. (#2504)
    • EnumerableMap: change implementation to optimize for key โ†’ value lookups instead of enumeration. (#2518)
    • GSN: deprecate GSNv1 support in favor of upcoming support for GSNv2. (#2521)
    • ERC165: remove uses of storage in the base ERC165 implementation. ERC165 based contracts now use storage-less virtual functions. Old behavior remains available in the ERC165Storage extension. (#2505)
    • Initializable: make initializer check stricter during construction. (#2531)
    • ERC721: remove enumerability of tokens from the base implementation. This feature is now provided separately through the ERC721Enumerable extension. (#2511)
    • AccessControl: removed enumerability by default for a more lightweight contract. It is now opt-in through AccessControlEnumerable. (#2512)
    • Meta Transactions: add ERC2771Context and a MinimalForwarder for meta-transactions. (#2508)
    • Overall reorganization of the contract folder to improve clarity and discoverability. (#2503)
    • ERC20Capped: optimize gas usage by enforcing the check directly in _mint. (#2524)
    • Rename UpgradeableProxy to ERC1967Proxy. (#2547)
    • ERC777: optimize the gas costs of the constructor. (#2551)
    • ERC721URIStorage: add a new extension that implements the _setTokenURI behavior as it was available in 3.4.0. (#2555)
    • AccessControl: added ERC165 interface detection. (#2562)
    • ERC1155: make uri public so overloading function can call it using super. (#2576)

    How to upgrade from 3.x

    Since this version has moved a few contracts to different directories, users upgrading from a previous version will need to adjust their import statements. To make this easier, the package includes a script that will migrate import statements automatically. After upgrading to the latest version of the package, run:

    npx openzeppelin-contracts-migrate-imports
    

    Make sure you're using git or another version control system to be able to recover from any potential error in our script.

    Source code(tar.gz)
    Source code(zip)
  • v4.0.0-beta.0(Feb 22, 2021)

  • v3.4.0(Feb 3, 2021)

    Read the full announcement in the blog or check out the changelog.

    Security Fixes

    • ERC777: fix potential reentrancy issues for custom extensions to ERC777. (#2483)

    If you're using our implementation of ERC777 from version 3.3.0 or earlier, and you define a custom _beforeTokenTransfer function that writes to a storage variable, you may be vulnerable to a reentrancy attack. If you're affected and would like assistance please write to [email protected] Read more in the pull request.

    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Nov 27, 2020)

    Read the full announcement in the forum or check out the changelog.

    • Now supports both Solidity 0.6 and 0.7. Compiling with solc 0.7 will result in warnings. Install the solc-0.7 tag to compile without warnings.
    • TimelockController: added a contract to augment access control schemes with a delay. (#2354)
    • Address: added functionStaticCall, similar to the existing functionCall. (#2333)
    • EnumerableSet: added Bytes32Set, for sets of bytes32. (#2395)
    Source code(tar.gz)
    Source code(zip)
  • v3.2.1-solc-0.7(Sep 15, 2020)

    This is a special release for Solidity 0.7 that gets rid of a warning in ERC777 using one of the new features of the language. (#2327)

    Note: The variant for Solidity 0.7 can be installed using npm install @openzeppelin/[email protected].

    Source code(tar.gz)
    Source code(zip)
  • v3.2.0(Sep 11, 2020)

    Welcome to a new release of OpenZeppelin Contracts! :dancers:

    The big feature in this release is that weโ€™ve migrated our proxy contracts from OpenZeppelin SDK into the Contracts project. We hope this will make more people aware of upgrades in Ethereum, and we also think the contracts will benefit greatly from the continued scrutiny by all of you in the community. This was also a migration of the proxies from Solidity 0.5 to 0.6, which we know some users have been waiting for.

    For Solidity 0.7 users, a reminder that we have support for the newer compiler version published on npm under the tag solc-0.7, the latest release being 3.2.0-solc-0.7. Weโ€™re considering officially switching to 0.7 for the release after this one.

    There is additionally a small breaking change in ERC20Snapshot that may affect some of its users. If youโ€™re one of them please take a look at the changelog.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Jun 29, 2020)

    This is the first release since v3.0, our last major release. It includes the long-awaited ERC1155 token and helpers for safe calls and downcasts, as well as a number of minor improvements.

    To install this release, run:

    npm install --save-dev @openzeppelin/contracts
    

    ERC1155

    This is a new token standard developed by the gaming industry, focusing on gas efficiency. It's key difference is that it is a multi-token contract: a single ERC1155 can be used to represent an arbitrary number of tokens, which is very useful in applications that require many tokens by removing the high gas costs associated with deploying them. Check out our new documentation page to learn more!.

    More Replacements for call

    The low-level call primitive can be hard to use correctly and is often considered unsafe. With the addition of sendValue in Contracts and try-catch in Solidity, there's only a few scenarios in which call is still needed, the most troublesome one being forwarding calls.

    The new functionCall helpers can forward call data to a recipient contract while imitating Solidity's function call semantics, such as bubbling up revert reasons and rejecting calls to EOAs. We expect the addition of these functions to greatly reduce the need to rely on call.

    Using SafeMath on Small Signed Integers

    We've expanded the scope of the SafeCast library to also include signed integer downcasting, which allows for users that need small types (such as int8 or int32) to perform checked arithmetic on them by using SafeMath, and then downcast the result to the intended size.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.1(Apr 27, 2020)

    This is a small bugfix release, addressing an issue that allowed for some internal functions in ERC777 to be called with the zero address as one of their arguments.

    This was reported in https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2208, fixed in https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2212 for the v2.5 branch, and ported to the v3.0 branch in https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2213.

    Source code(tar.gz)
    Source code(zip)
  • v2.5.1(Apr 27, 2020)

    This is a small bugfix release, addressing an issue that allowed for some internal functions in ERC777 to be called with the zero address as one of their arguments.

    This was reported in https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2208 and fixed in https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2212.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(Apr 20, 2020)

    We're thrilled to finally announce the release of OpenZeppelin Contracts v3.0 :sparkles:

    Among other things, this release features the migration to Solidity v0.6, as well as a revamped access control system, streamlined token contracts, and new libraries for enumerable mappings.

    To install this latest release, run:

    npm install --save-dev @openzeppelin/contracts
    

    What's New

    • All contracts were migrated to Solidity v0.6.
    • AccessControl was designed with help from the community and has replaced Roles contracts (such as MinterRole and PauserRole), which were removed.
    • Crowdsales were removed: we'll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.
    • We've added hooks, a new feature of the library that will make extending it easier than ever.
    • ERC20 and ERC721 were simplified and streamlined, including all optional parts of the standard by default, and simplifying some of our own custom extensions.
    • Support for better mapping types that let you efficiently iterate over all keys using EnumerableSet and EnumerableMap
    • Many, many breaking changes with small improvements. We've also moved some contracts around (e.g. Ownable is now found under the access directory) and deleted some that were not being used. Head to our changelog to see the full list.

    Compiling v0.6 Contracts

    You can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you'll be good to go!

    pragma solidity ^0.6.0;
    

    Note that you will need to use the v2.7 release of the CLI or newer to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.

    Revamped Access Control

    One of our most widely-used contracts is Ownable, providing a simple authorization scheme. However, this fell short in complex systems with multiple permissions.

    The v3.0 release introduces AccessControl, a one-stop-shop for all authorization needs. It lets you easily define multiple roles with different permissions, as well as which accounts are allowed to grant and revoke each role. It also boosts transparency by enabling enumeration of all privileged accounts in a system.

    AccessControl was designed with a security-first mindset, receiving input from a wide array of users and incorporating best practices in the field. Head to our Access Control guide for more information!

    Preset Contracts

    OpenZeppelin Contracts shine when you need the building blocks to get to the right feature set, but that's not all they can do! We've added a new family of Preset contracts starting with ERC20 and ERC721 tokens that you can quickly deploy as-is without having to write any Solidity code. Check out their documentation!

    Migrating From OpenZeppelin Contracts v2.5

    Other than the moved and deleted contracts mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.

    If you're using the ERC20 or ERC721 tokens however, you'll have to remove all references to optional extensions (ERC20Detailed, ERC721Enumerable, etc.) - these have been included in the base contracts.

    The other exception to this are contracts that use the Gas Station Network (GSN): if you're inheriting from GSNRecipient or one of the other GSN contracts, you'll need to add the following snippet to your contracts:

    function _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {
        return GSNRecipient._msgSender();
    }
    
    function _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {
        return GSNRecipient._msgData();
    }
    

    Using Hooks

    To improve library flexibility, we're introducing hooks: functions that are called at specific moments during a contract's operation that you can use to hook into the internals and extend as you wish.

    For example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.

    // Tokens can only be transferred, minted or burned if the contract is not paused
    contract ERC20Pausable is ERC20, Pausable {
        function _beforeTokenTransfer(address from, address to, uint256 amount) 
            internal virtual override 
        {
            super._beforeTokenTransfer(from, to, amount);
    
            require(!paused(), "ERC20Pausable: token transfer while paused");
        }
    }
    

    As an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.

    Head over to our brand new guide on Extending the OpenZeppelin Contracts to learn more!

    What's Next

    We've started work in some exciting features for the upcoming releases, including fixed-point arithmetic and the ERC1155 token standard. To read more and find out how you can contribute, check out our Q2 2020 roadmap!

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0-beta.0(Feb 15, 2020)

    We're excited to announce the beta release of OpenZeppelin Contracts v3.0 :sparkles:

    This is the main item in Contract's roadmap, featuring the migration to Solidity v0.6.

    To install the beta release, run:

    npm install --save-dev @openzeppelin/[email protected]
    

    What's Included in the Beta

    The final v3.0 release is not yet finished, but we're putting together this beta version early to ease the transition to this new Solidity version for the community.

    Here's what you will find in the beta:

    • All contracts were migrated to ^0.6.0.
    • Roles contracts (such as MinterRole and PauserRole) were removed: we're redesigning our Access Control solution and will have a better version of these in the v3.0 release.
    • Crowdsales were removed: we'll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.
    • We've added hooks, a new feature of the library that will make extending it easier than ever. Read more below!

    We expect for the final v3.0 release to come out in early March. If you want to contribute, head to our list of pending changes: most of them can be tackled quickly by beginner and intermediate users!

    Compiling v0.6 Contracts

    You can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you'll be good to go!

    pragma solidity ^0.6.0;
    

    Note that you will need to use the recent v2.7 release of the CLI to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.

    Migrating From OpenZeppelin Contracts v2.5

    Other than the contract removals mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.

    The exception to this is contracts that use the Gas Station Network (GSN): if you're inheriting from GSNRecipient or one of the other GSN contracts, you'll need to add the following snippet to your contracts:

    function _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {
        return GSNRecipient._msgSender();
    }
    
    function _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {
        return GSNRecipient._msgData();
    }
    

    Using Hooks

    To improve library flexibility, we're introducing hooks: functions that are called at specific moments during a contract's operation that you can use to hook into the internals and extend as you wish.

    For example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.

    // Tokens can only be transferred, minted or burned if the contract is not paused
    contract ERC20Pausable is ERC20, Pausable {
        function _beforeTokenTransfer(address from, address to, uint256 amount) 
            internal virtual override 
        {
            super._beforeTokenTransfer(from, to, amount);
    
            require(!paused(), "ERC20Pausable: token transfer while paused");
        }
    }
    

    As an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.

    Next Steps

    The final v3.0 release is still a couple weeks away, but you can help us get there faster! Head to the list of v3.0 pending changes to learn about areas where you can contribute, or take a look at Contract's roadmap for more information on the general direction we're taking.

    While you wait for v3.0 to come out, check out the recent v2.5 release, the final OpenZeppelin Contracts release with support for Solidity v0.5, and our newly improved documentation site, with tons of guides, API References and other learning resources!

    Source code(tar.gz)
    Source code(zip)
  • v2.5.0(Feb 5, 2020)

    We're very happy the announce the release of OpenZeppelin Contracts v2.5!

    This new release features:

    • EnumerableSet: similar to Solidity's mapping, but that lets you retrieve all the keys! Useful for dapps that need to display a set of accounts with some property, and cannot rely on events alone.
    • Create2: a simple library for using the CREATE2 opcode, allowing for deployment and pre-computation of addresses when using it. To learn more about all the cool things you can do with it, head to Getting the Most out of CREATE2
    • ERC721Metadata.baseURI: a neat extension for massive gas savings when the token URIs share a prefix, like https://my.cool.app/token/<id>

    There are also some minor improvements, such as gas optimizations for ReentrancyGuard and additional extensibility of ERC777, among others.

    For the complete list of changes, head to our changelog.

    To install the new release, run:

    $ npm install @openzeppelin/[email protected]
    

    New Documentation :books:

    We've also recently done some some improvements to our documentation website, including new detailed guides and documentation for our other tools, such as the Test Helpers, our blazing-fast Test Environment and the OpenZeppelin Command Line Interface. Check them out for a radically better development experience!

    Saying Goodbye to Solidity v0.5 :wave:

    December 2019 saw the release of Solidity v0.6. This new version of the language has major improvements, and we're already underway to release the next version of OpenZeppelin Contracts with support for Solidity v0.6.

    However, it also includes a lot of breaking changes, making it difficult to support both v0.5 and v0.6 code at the same time. For this reason, we've decided OpenZeppelin Contracts v2.5 will be the last version supporting Solidity v0.5.

    The exciting good news it that the next OpenZeppelin Contracts release will be v3.0, where we'll get to redesign some quirky bits of the library, improving ease of use and flexibility. Stay tuned!

    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Nov 1, 2019)

    In 2.4 we're releasing support for the Gas Station Network for user onboarding and metatransactions :fuelpump:, new functions to safeguard your contracts against the Istanbul hard fork, and improvements to error messages.

    Read the full announcement in the OpenZeppelin Forum, and make sure to check out the details in the changelog!

    Enjoy!

    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Jun 3, 2019)

    In 2.3 we're introducing ERC777, revert reasons, and a new documentation site. :fireworks: Take a look and tell us what you think in the announcement thread!

    Take a look and tell us what you think!

    ERC777

    The long awaited sequel to ERC20. Its main additions are transfer hooks and operators. Hooks let your contracts react to token transfers. In other words, running code when a contract receives tokens is a built-in feature: no more messing around with approve and transferFrom!

    The other special feature, operators, provides simpler and more flexible ways of delegating usage of your tokens to other people or contracts, like decentralized exchanges.

    All of this with full compatibility with ERC20!

    Start building on it and tell us what you think! We're looking for ideas for extensions, custom operators, or utilities. Share your ideas here or in a new thread.

    Revert reasons

    Are you tired of running into cryptic errors like VM Exception while processing transaction: revert? All errors in OpenZeppelin now have proper error messages that will be displayed when you test your code! We've kept them succinct and to the point. Each error message is unique, so if you're having trouble figuring out exactly which require statement you've hit, it is easy to look up the error string in the source code, and look at the actual condition that is not being met.

    Documentation site

    We've revamped the docs, take a look!

    It'll be super helpful to both people looking to get started in smart contract development, and veteran OpenZeppelin users who just need to quickly recall a function signature. Among other improvements, we've bundled together related concepts, added overviews for each section, and added crosslinks to other contracts and functions to make exploring the docsite a breeze!

    Everything is automatically generated from the comments in the source code, so if you spot a typo or have a suggestion, simply open an issue or PR to get it sorted out in no time!

    Some sections still require a bit of work to get them to where we want them to be, stay tuned!

    More

    Some more things are included in this release such as an implementation of ERC1820, and a fix for a bug in PostDeliveryCrowdsale. Take a look at the changelog! We have revamped the documentation site infrastructure and feel, take a look! It'll be super helpful to both people looking to get started in smart contract development and OpenZeppelin, and veteran users who just need to quickly recall an API. Among other improvements, we've bundled together related concepts, added overviews for each section, and added crosslinks to other contracts and functions to make exploring the docsite a breeze!

    Everything is automatically generated from the comments in the source code, so if you spot a typo or have a suggestion, simply open an issue or PR to get it sorted out in no time!

    Some sections still require a bit of work to get them to where we want them to be, stay tuned!

    More

    Some more things are included in this release such as an implementation of ERC1820, and a fix for a bug in PostDeliveryCrowdsale. Take a look at the changelog!

    Source code(tar.gz)
    Source code(zip)
Owner
OpenZeppelin
The standard for secure blockchain applications
OpenZeppelin
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

null 0 Jan 4, 2022
DERO: Secure, Anonymous Blockchain with Smart Contracts. Subscribe to Dero announcements by sending mail to [email protected] 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

null 274 May 22, 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

null 2 Apr 22, 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

Tally 33 May 27, 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 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.

Offchain Labs 808 Jun 21, 2022
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

SundaeSwap Finance 140 Jun 3, 2022
Accompanying repository for the "Build Ethereum From Scratch - Smart Contracts and More" course by David Katz

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

David Katz 38 May 13, 2022
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

Juno 203 Jun 25, 2022
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

Nuxify Inc. 3 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

ConsenSys Software 5.8k Jun 21, 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

EOSIO 11.3k Jun 20, 2022
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

null 37 Jun 7, 2022
Contracts for the versus-flow.art project

Versus Flow Auction Contract This is a git repo for the cadence contrats for [email protected] Follow the guide below to set it up and test locally in the

Versus@Flow 11 Apr 22, 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

byterocket 66 Jun 28, 2022
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

Cossack Labs 1.5k Jun 30, 2022
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

Ali Shokoohi 1 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

Sina Khalili 1 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.

Anatol Pomozov 99 Jun 23, 2022
The bare metal Go smart card

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

F-Secure Foundry 131 May 13, 2022