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.

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

    opened by abcoathup 50
  • 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
  • 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

    feature contracts 
    opened by barakman 33
  • 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
  • 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
    opened by heldersepu 30
  • 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
  • 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
    opened by Amxx 0
  • 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.

    opened by alex-ppg 16
  • 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
    ignore-changelog 
    opened by Amxx 0
  • 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.

    breaking change 
    opened by frangio 8
  • 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.

    breaking change area: governance 
    opened by frangio 0
Releases(v4.8.0)
  • v4.8.0(Nov 8, 2022)

    Note Don't miss the section on Breaking changes at the end.

    • TimelockController: Added a new admin constructor parameter that is assigned the admin role instead of the deployer account. (#3722)
    • Initializable: add internal functions _getInitializedVersion and _isInitializing (#3598)
    • ERC165Checker: add supportsERC165InterfaceUnchecked for consulting individual interfaces without the full ERC165 protocol. (#3339)
    • Address: optimize functionCall by calling functionCallWithValue directly. (#3468)
    • Address: optimize functionCall functions by checking contract size only if there is no returned data. (#3469)
    • Governor: make the relay function payable, and add support for EOA payments. (#3730)
    • GovernorCompatibilityBravo: remove unused using statements. (#3506)
    • ERC20: optimize _transfer, _mint and _burn by using unchecked arithmetic when possible. (#3513)
    • ERC20Votes, ERC721Votes: optimize getPastVotes for looking up recent checkpoints. (#3673)
    • ERC20FlashMint: add an internal _flashFee function for overriding. (#3551)
    • ERC4626: use the same decimals() as the underlying asset by default (if available). (#3639)
    • ERC4626: add internal _initialConvertToShares and _initialConvertToAssets functions to customize empty vaults behavior. (#3639)
    • ERC721: optimize transfers by making approval clearing implicit instead of emitting an event. (#3481)
    • ERC721: optimize burn by making approval clearing implicit instead of emitting an event. (#3538)
    • ERC721: Fix balance accounting when a custom _beforeTokenTransfer hook results in a transfer of the token under consideration. (#3611)
    • ERC721: use unchecked arithmetic for balance updates. (#3524)
    • ERC721Consecutive: Implementation of EIP-2309 that allows batch minting of ERC721 tokens during construction. (#3311)
    • ReentrancyGuard: Reduce code size impact of the modifier by using internal functions. (#3515)
    • SafeCast: optimize downcasting of signed integers. (#3565)
    • ECDSA: Remove redundant check on the v value. (#3591)
    • VestingWallet: add releasable getters. (#3580)
    • VestingWallet: remove unused library Math.sol. (#3605)
    • VestingWallet: make constructor payable. (#3665)
    • Create2: optimize address computation by using assembly instead of abi.encodePacked. (#3600)
    • Clones: optimized the assembly to use only the scratch space during deployments, and optimized predictDeterministicAddress to use fewer operations. (#3640)
    • Checkpoints: Use procedural generation to support multiple key/value lengths. (#3589)
    • Checkpoints: Add new lookup mechanisms. (#3589)
    • Arrays: Add unsafeAccess functions that allow reading and writing to an element in a storage array bypassing Solidity's "out-of-bounds" check. (#3589)
    • Strings: optimize toString. (#3573)
    • Ownable2Step: extension of Ownable that makes the ownership transfers a two step process. (#3620)
    • Math and SignedMath: optimize function max by using > instead of >=. (#3679)
    • Math: Add log2, log10 and log256. (#3670)
    • Arbitrum: Update the vendored arbitrum contracts to match the nitro upgrade. (#3692)

    Breaking changes

    • ERC721: In order to add support for batch minting via ERC721Consecutive it was necessary to make a minor breaking change in the internal interface of ERC721. Namely, the hooks _beforeTokenTransfer and _afterTokenTransfer have one additional argument that may need to be added to overrides:
     function _beforeTokenTransfer(
         address from,
         address to,
         uint256 tokenId,
    +    uint256 batchSize
     ) internal virtual override
    
    • ERC4626: Conversion from shares to assets (and vice-versa) in an empty vault used to consider the possible mismatch between the underlying asset's and the vault's decimals. This initial conversion rate is now set to 1-to-1 irrespective of decimals, which are meant for usability purposes only. The vault now uses the assets decimals by default, so off-chain the numbers should appear the same. Developers overriding the vault decimals to a value that does not match the underlying asset may want to override the _initialConvertToShares and _initialConvertToAssets to replicate the previous behavior.

    • TimelockController: During deployment, the TimelockController used to grant the TIMELOCK_ADMIN_ROLE to the deployer and to the timelock itself. The deployer was then expected to renounce this role once configuration of the timelock is over. Failing to renounce that role allows the deployer to change the timelock permissions (but not to bypass the delay for any time-locked actions). The role is no longer given to the deployer by default. A new parameter admin can be set to a non-zero address to grant the admin role during construction (to the deployer or any other address). Just like previously, this admin role should be renounced after configuration. If this param is given address(0), the role is not allocated and doesn't need to be revoked. In any case, the timelock itself continues to have this role.

    Deprecations

    • EIP712: Added the file EIP712.sol and deprecated draft-EIP712.sol since the EIP is no longer a Draft. Developers are encouraged to update their imports. (#3621)
    -import "@openzeppelin/contracts/utils/cryptography/draft-EIP712.sol";
    +import "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
    
    • ERC721Votes: Added the file ERC721Votes.sol and deprecated draft-ERC721Votes.sol since it no longer depends on a Draft EIP (EIP-712). Developers are encouraged to update their imports. (#3699)
    -import "@openzeppelin/contracts/token/ERC721/extensions/draft-ERC721Votes.sol";
    +import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Votes.sol";
    

    ERC-721 Compatibility Note

    ERC-721 integrators that interpret contract state from events should make sure that they implement the clearing of approval that is implicit in every transfer according to the EIP. Previous versions of OpenZeppelin Contracts emitted an explicit Approval event even though it was not required by the specification, and this is no longer the case.

    With the new ERC721Consecutive extension, the internal workings of ERC721 are slightly changed. Custom extensions to ERC721 should be reviewed to ensure they remain correct. The internal functions that should be considered are _ownerOf (new), _beforeTokenTransfer, and _afterTokenTransfer.

    Source code(tar.gz)
    Source code(zip)
  • v4.8.0-rc.1(Sep 23, 2022)

    This prerelease is now available for open review! Try it out, look at the code, and share your feedback.

    In addition to all the changes in 4.8.0-rc.0, this new release candidate improves the timelock configuration process and updates part of the documentation.

    • βŒ› TimelockController: Add a new admin constructor parameter that is assigned the admin role instead of the deployer account.
    • πŸ“– Some documentation improvements.

    Breaking changes TimelockController: During deployment, the TimelockController used to grant the TIMELOCK_ADMIN_ROLE to the deployer and to the timelock itself. The deployer was then expected to renounce this role once configuration of the timelock is over. Failing to renounce that role allows the deployer to change the timelock permissions (but not to bypass the delay for any time-locked actions). The role is no longer given to the deployer by default. A new parameter admin can be set to a non-zero address to grant the admin role during construction (to the deployer or any other address). Just like previously, this admin role should be renounced after configuration. If this param is given address(0), the role is not allocated and doesn't need to be revoked. In any case, the timelock itself continues to have this role.

    See the changelog for all the release details.

    Source code(tar.gz)
    Source code(zip)
  • v4.8.0-rc.0(Sep 8, 2022)

    This prerelease is now available for open review! Try it out, look at the code, and share your feedback.

    To reward issues found we have a bug bounty going up to $25,000 with an additional reward for any findings introduced in this release candidate.

    • β›½ ERC721Consecutive: Efficient batch minting of NFTs (EIP-2309)
    • β›½ Optimizations in ERC20Votes, ERC721Votes: Best case cost reduced to 50%!
    • πŸ†• Ownable2Step: An extension of Ownable with 2-step transferOwnership
    • πŸ†• Math.log2/log10: Integer logarithm
    • πŸ’― ERC4626 decimals changes: Remove decimals from on-chain calculations
    • β›½ Many small optimizations

    See the changelog for all the release details.

    Source code(tar.gz)
    Source code(zip)
  • v4.7.3(Aug 10, 2022)

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

    Breaking changes

    • ECDSA: recover(bytes32,bytes) and tryRecover(bytes32,bytes) no longer accept compact signatures to prevent malleability. Compact signature support remains available using recover(bytes32,bytes32,bytes32) and tryRecover(bytes32,bytes32,bytes32).
    Source code(tar.gz)
    Source code(zip)
  • v4.7.2(Jul 28, 2022)

    :warning: This is a patch for three issues, including a high severity issue in GovernorVotesQuorumFraction. For more information visit the security advisories (1, 2, 3).

    1. GovernorVotesQuorumFraction: Fixed quorum updates so they do not affect past proposals that failed due to lack of quorum. (#3561)
    2. ERC165Checker: Added protection against large returndata. (#3587)
    3. LibArbitrumL2, CrossChainEnabledArbitrumL2: Fixed detection of cross-chain calls for EOAs. Previously, calls from EOAs would be classified as cross-chain calls. (#3578)
    Source code(tar.gz)
    Source code(zip)
  • v4.7.1(Jul 20, 2022)

    :warning: This is a patch for a medium severity issue affecting SignatureChecker and a high severity issue affecting ERC165Checker. For more information visit the security advisories (1, 2).

    • SignatureChecker: Fix an issue that causes isValidSignatureNow to revert when the target contract returns ill-encoded data. (#3552)
    • ERC165Checker: Fix an issue that causes supportsInterface to revert when the target contract returns ill-encoded data. (#3552)
    Source code(tar.gz)
    Source code(zip)
  • v4.7.0(Jun 30, 2022)

    • TimelockController: Migrate _call to _execute and allow inheritance and overriding similar to Governor. (#3317)
    • CrossChainEnabledPolygonChild: replace the require statement with the custom error NotCrossChainCall. (#3380)
    • ERC20FlashMint: Add customizable flash fee receiver. (#3327)
    • ERC4626: add an extension of ERC20 that implements the ERC4626 Tokenized Vault Standard. (#3171)
    • SafeERC20: add safePermit as mitigation against phantom permit functions. (#3280)
    • Math: add a mulDiv function that can round the result either up or down. (#3171)
    • Math: Add a sqrt function to compute square roots of integers, rounding either up or down. (#3242)
    • Strings: add a new overloaded function toHexString that converts an address with fixed length of 20 bytes to its not checksummed ASCII string hexadecimal representation. (#3403)
    • EnumerableMap: add new UintToUintMap map type. (#3338)
    • EnumerableMap: add new Bytes32ToUintMap map type. (#3416)
    • SafeCast: add support for many more types, using procedural code generation. (#3245)
    • MerkleProof: add multiProofVerify to prove multiple values are part of a Merkle tree. (#3276)
    • MerkleProof: add calldata versions of the functions to avoid copying input arrays to memory and save gas. (#3200)
    • ERC721, ERC1155: simplified revert reasons. (#3254, (#3438))
    • ERC721: removed redundant require statement. (#3434)
    • PaymentSplitter: add releasable getters. (#3350)
    • Initializable: refactored implementation of modifiers for easier understanding. (#3450)
    • Proxies: remove runtime check of ERC1967 storage slots. (#3455)

    Breaking changes

    • Initializable: functions decorated with the modifier reinitializer(1) may no longer invoke each other.
    Source code(tar.gz)
    Source code(zip)
  • 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)
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 275 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

null 3 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

Tally 34 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 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 1k Jan 8, 2023
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 138 Dec 19, 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 46 Dec 7, 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 255 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

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 6.4k 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

EOSIO 11.3k 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

null 43 Dec 14, 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 12 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

byterocket 142 Jan 9, 2023
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.6k 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

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 121 Dec 27, 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 146 Dec 8, 2022