2021-10-21 12:06:30 +00:00
|
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
pragma solidity ^0.8.0;
|
|
|
|
|
|
|
|
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
|
|
|
|
|
2023-09-13 00:03:31 +00:00
|
|
|
/* The `increaseAllowance` function of OpenZeppelin's ERC20 implementation is
|
2023-09-13 00:02:00 +00:00
|
|
|
being used, which is not part of the standard ERC20 interface. If the Codex
|
|
|
|
token must be an ERC20 token (eg DAI), then that token will need to be wrapped in
|
|
|
|
OpenZeppelin's ERC20Wrapped to ensure that `increaseAllowance` is available.
|
|
|
|
|
|
|
|
The reason `increaseAllowance` is needed is because the sales state machine
|
|
|
|
handles concurrent slot fills, which requires token approval. Because these
|
|
|
|
approvals happen concurrently, simply calling `approve` is not sufficient as
|
|
|
|
each `approve` amount will overwrite the previous. As an example, if a single
|
2023-09-13 00:03:31 +00:00
|
|
|
node attempts to fill two slots simultaneously, it will send two `approve`
|
2023-09-13 00:02:00 +00:00
|
|
|
transactions followed by two `fillSlot` transactions. The first two `approve`
|
|
|
|
transactions will each approve the collateral amount for one `fillSlot`, the
|
|
|
|
second overwriting the first, so the total approved will only ever be enough for
|
|
|
|
one `fillSlot`. So after the first `fillSlot` is sent, the second one will fail
|
|
|
|
as not enough tokens will have been approved. The solution is use
|
|
|
|
`increaseAllowance` instead of `approve` which increases the allowance instead
|
|
|
|
of overwriting it. */
|
|
|
|
|
2021-10-21 12:06:30 +00:00
|
|
|
contract TestToken is ERC20 {
|
2022-02-09 13:37:55 +00:00
|
|
|
// solhint-disable-next-line no-empty-blocks
|
2021-11-16 13:25:42 +00:00
|
|
|
constructor() ERC20("TestToken", "TST") {}
|
|
|
|
|
2022-02-09 13:17:23 +00:00
|
|
|
function mint(address holder, uint256 amount) public {
|
2021-11-23 13:34:27 +00:00
|
|
|
_mint(holder, amount);
|
2021-10-21 12:06:30 +00:00
|
|
|
}
|
|
|
|
}
|