codex-contracts-eth/contracts/TestToken.sol

32 lines
1.5 KiB
Solidity
Raw Normal View History

// 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. */
contract TestToken is ERC20 {
2022-02-09 13:37:55 +00:00
// solhint-disable-next-line no-empty-blocks
constructor() ERC20("TestToken", "TST") {}
2022-02-09 13:17:23 +00:00
function mint(address holder, uint256 amount) public {
_mint(holder, amount);
}
}