Drafts

This contract can be used to migrate an ERC20 token from one contract to another, where each token holder has to opt-in to the migration. To opt-in, users must approve for this contract the number of tokens they want to migrate. Once the allowance is set up, anyone can trigger the migration to the new token contract. In this way, token holders "turn in" their old balance and will be minted an equal amount in the new token. The new token contract must be mintable. For the precise interface refer to OpenZeppelin’s ERC20Mintable, but the only functions that are needed are MinterRole.isMinter and ERC20Mintable.mint. The migrator will check that it is a minter for the token. The balance from the legacy token will be transferred to the migrator, as it is migrated, and remain there forever. Although this contract can be used in many different scenarios, the main motivation was to provide a way to migrate ERC20 tokens into an upgradeable version of it using ZeppelinOS. To read more about how this can be done using this implementation, please follow the official documentation site of ZeppelinOS: https://docs.zeppelinos.org/docs/erc20_onboarding.html

Example of usage:

Inspired by Jordi Baylina’s MiniMeToken to record historical balances.

When a snapshot is made, the balances and total supply at the time of the snapshot are recorded for later access.

To make a snapshot, call the Snapshot function, which will emit the Snapshot event and return a snapshot id. To get the total supply from a snapshot, call the function totalSupplyAt with the snapshot id. To get the balance of an account from a snapshot, call the balanceOfAt function with the snapshot id and the account address.

A token holder contract that can release its token balance gradually like a typical vesting scheme, with a cliff and vesting period. Optionally revocable by the owner.

Provides counters that can only be incremented or decremented by one. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids.

Include with using Counters for Counters.Counter; Since it is not possible to overflow a 256 bit integer with increments of one, increment can skip the SafeMath overflow check, thereby saving gas. This does assume however correct usage, in that the underlying _value is never directly accessed.

SignatureBouncer allows users to submit a signature as a permission to do an action. If the signature is from one of the authorized signer addresses, the signature is valid. Note that SignatureBouncer offers no protection against replay attacks, users must add this themselves!

Signer addresses can be individual servers signing grants or different users within a decentralized club that have permission to invite other members. This technique is useful for whitelists and airdrops; instead of putting all valid addresses on-chain, simply sign a grant of the form keccak256(abi.encodePacked(:contractAddress + :granteeAddress)) using a valid signer address. Then restrict access to your crowdsale/whitelist/airdrop using the onlyValidSignature modifier (or implement your own using _isValidSignature). In addition to onlyValidSignature, onlyValidSignatureAndMethod and onlyValidSignatureAndData can be used to restrict access to only a given method or a given method with given parameters respectively. See the tests in SignatureBouncer.test.js for specific usage examples.

Signed math operations with safety checks that revert on error.