codex-storage
/
codex-contracts-eth
mirror of https://github.com/codex-storage/codex-contracts-eth.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

clean up

This commit is contained in:
Eric 2023-09-13 10:03:31 +10:00
parent dd17e6f2b2
commit 1da7ae190a
No known key found for this signature in database
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
contracts/TestToken.sol
View File

@ -3,7 +3,7 @@ pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
/* The `increaseAllowance` funcation of OpenZeppelin's ERC20 implementation is
/* The `increaseAllowance` function of OpenZeppelin's ERC20 implementation is
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.
@ -12,7 +12,7 @@ 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
node attempts to fill two slots simulataneously, it will send two `approve`
node attempts to fill two slots simultaneously, it will send two `approve`
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