Drafts
| This page is incomplete. We’re working to improve it for the next release. Stay tuned! |
ERC 20
ERC20Migrator
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:
const migrator = await ERC20Migrator.new(legacyToken.address);
await newToken.addMinter(migrator.address);
await migrator.beginMigration(newToken.address);beginMigration(contract ERC20Mintable newToken_) public
Begins the migration by setting which is the new token that will be minted. This contract must be a minter for the new token.
ERC20Snapshot
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.
totalSupply() → uint256 public
See IERC20.totalSupply.
balanceOf(address account) → uint256 public
See IERC20.balanceOf.
transfer(address recipient, uint256 amount) → bool public
See IERC20.Transfer.
Requirements:
-
recipientcannot be the zero address. -
the caller must have a balance of at least
amount.
allowance(address owner, address spender) → uint256 public
See IERC20.allowance.
approve(address spender, uint256 value) → bool public
See IERC20.approve.
Requirements:
-
spendercannot be the zero address.
transferFrom(address sender, address recipient, uint256 amount) → bool public
See IERC20.transferFrom.
Emits an Approval event indicating the updated allowance. This is not
required by the EIP. See the note at the beginning of ERC20;
Requirements:
- sender and recipient cannot be the zero address.
- sender must have a balance of at least value.
- the caller must have allowance for sender’s tokens of at least
`amount.
increaseAllowance(address spender, uint256 addedValue) → bool public
Atomically increases the allowance granted to spender by the caller.
This is an alternative to approve that can be used as a mitigation for
problems described in IERC20.approve.
Emits an Approval event indicating the updated allowance.
Requirements:
-
spendercannot be the zero address.
decreaseAllowance(address spender, uint256 subtractedValue) → bool public
Atomically decreases the allowance granted to spender by the caller.
This is an alternative to approve that can be used as a mitigation for
problems described in IERC20.approve.
Emits an Approval event indicating the updated allowance.
Requirements:
-
spendercannot be the zero address. -
spendermust have allowance for the caller of at leastsubtractedValue.
_approve(address owner, address spender, uint256 value) internal
Sets amount as the allowance of spender over the `owner`s tokens.
This is internal function is equivalent to approve, and can be used to
e.g. set automatic allowances for certain subsystems, etc.
Emits an Approval event.
Requirements:
-
ownercannot be the zero address. -
spendercannot be the zero address.
_burnFrom(address account, uint256 amount) internal
Destroys amount tokens from account.amount is then deducted
from the caller’s allowance.
Transfer(address from, address to, uint256 value) event
Emitted when value tokens are moved from one account (from) to
another (to).
Note that value may be zero.
Approval(address owner, address spender, uint256 value) event
Emitted when the allowance of a spender for an owner is set by
a call to approve. value is the new allowance.
TokenVesting
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.
constructor(address beneficiary, uint256 start, uint256 cliffDuration, uint256 duration, bool revocable) public
Creates a vesting contract that vests its balance of any ERC20 token to the beneficiary, gradually in a linear fashion until start + duration. By then all of the balance will have vested.
renounceOwnership() public
Leaves the contract without owner. It will not be possible to call
onlyOwner functions anymore. Can only be called by the current owner.
| Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner. |
transferOwnership(address newOwner) public
Transfers ownership of the contract to a new account (newOwner).
Can only be called by the current owner.
Miscellaneous
Counters
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
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.
onlyValidSignature(bytes signature) modifier
Requires that a valid signature of a signer was provided.
onlyValidSignatureAndMethod(bytes signature) modifier
Requires that a valid signature with a specified method of a signer was provided.
onlyValidSignatureAndData(bytes signature) modifier
Requires that a valid signature with a specified method and params of a signer was provided.
_isValidSignature(address account, bytes signature) → bool internal
is the signature of this + account from a signer?
_isValidSignatureAndMethod(address account, bytes signature) → bool internal
is the signature of this + account + methodId from a signer?
_isValidSignatureAndData(address account, bytes signature) → bool internal
is the signature of this + account + methodId + params(s) from a signer?