Token Report Crowdsale Contract Audit
Token Report intends to run a crowdsale commencing in October 2017.
Token Report’s white paper can be found here.
Bok Consulting Pty Ltd was commissioned to perform an audit on the Ethereum smart contracts for Token Report’s token contracts.
No potential vulnerabilities have been identified in this token contract.
There are some differences in the token contract behaviour compared to the recently finalised ERC20 token standard, but none of these are significant.
The token contract consist of Token, Controller and Ledger contracts working together. Funds collected during the crowdsale will be used to
calculate the token balances in this token contract, and the token balances will be minted in this token contract by an external program executing
the Ledger.multiMint(...) function. Once the minting is completed, the Ledger.stopMinting() function is execute to prevent any further token
minting.
The source code for this audit have been extracted from the verified source code on EtherScan:
Note that source code is exactly the same in each of these three source code files, as expected.
Together, the contracts provide the general functionality required of an ERC20 Token Standard
token. There are some slight difference in behaviour compared to this recently (Sep 11 2017) finalised standard and these differences are listed
below:
Token.transfer(...) returns false if there are insufficient tokens to transfer. In the recently finalised ERC20 token standard:
The function SHOULD throw if the _from account balance does not have enough tokens to spend.
Token.transfer(...) returns false as required under the previous un-finalised version of the ERC20 token standard
Token.transferFrom(...) returns false if there are insufficient tokens to transfer or insufficient tokens have been approved for transfer.
In the recently finalised ERC20 token standard:
The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism
Token.transferFrom(...) returns false as required under the previous un-finalised version of the ERC20 token standard
Token.approve(...) requires that a non-0 approval limit be set to 0 before being modified to another non-0 approval limit. In the recently
finalised ERC20 token standard:
… clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value
for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatilibilty with contracts deployed before
Token.approve(...) implements the requirement to set a non-0 approval limit to 0 before modifying the limit to another non-0 approval limit
that was a standard practice for ERC20 tokens before the recent ERC20 token standard was finalised
Token.transfer(...), Token.approve(...) and Token.transferFrom(...) all implement the onlyPayloadSize(...) check that was recently
relatively common in ERC20 token contracts, but has now been generally discontinued as it was found to be ineffective. See
Smart Contract Short Address Attack Mitigation Failure
for further information. The version used in the Token contract checks for a minimum payload size (using the >= operator) and should not
cause any problems with multisig wallets as documented in the link.
None of the differences above are significant to the workings of an ERC20 token.
Transfers in the Token contract can be paused and un-paused by the token contract owner, at any time
The owner of the Token, Controller and Ledger contracts can use the setToken(...), setController(...) and setLedger(...) functions
to bypass the intended permissioning in this system of contracts and execute some of the functions with irregular operations. As an example,
the owner of Ledger can call setController({owner account}) and then execute burn(...) to burn the tokens of any account
No potential vulnerabilities have been identified in this token contract.
This audit is into the technical aspects of the token contract. The aim of this audit is to ensure that token balances and transfers
cannot easily be attacked or stolen by third parties. This audit does not guarantee that that the code is bugfree, but intends to
highlight any areas of weaknesses.
The following functions were tested using the script test/01_test1.sh with the summary results saved
in test/test1results.txt and the detailed output saved in test/test1output.txt:
transfer(...), approve(...) and transferFrom(...) of tokenstransfer(...), approve(...) and transferFrom(...) of tokenstransfer(...), approve(...) and transferFrom(...) of 0 tokensThis section looks across the permissions required to execute the non-constant functions in these set of contracts.
All three main contracts Token, Controller and Ledger are derived from Finalizable which is derived from Owned. They all implementFinalizable.finalize() that can only be called by the owner. They also implement Owned.changeOwner(...) that can only be called by
owner, and Owned.acceptOwnership() that can only be called by the new intended owner.
[x] Token additionally is derived from TokenReceivable that implements TokenReceivable.claimTokens(...) and this can only be called owner
[x] Token.setController(...) can only be called by owner
[x] Token.controllerApprove(...) can only be called by Controller. As Controller does not have any functions to callToken.controllerApprove(...), this function is redundant
Controller.setToken(...) and Controller.setLedger(...) that can only be called by owner[x] Ledger.multiMint(...) can only be called by owner
Contoller.ledgerTransfer(...) that can only be called by LedgerToken.controllerTransfer(...) that can only be called by Controller[x] Ledger has a Ledger.setController(...) and a Ledger.stopMinting(...) that can only be called by owner
Following are the Token functions that can be executed by any account
[x] Token.transfer(...)
Controller.transfer(...) that can only be called by TokenLedger.transfer(...) that can only be called by Controller[x] Token.transferFrom(...)
Controller.transferFrom(...) that can only be called by TokenLedger.transferFrom(...) that can only be called by Controller[x] Token.approve(...)
Controller.approve(...) that can only be called by TokenLedger.approve(...) that can only be called by Controller[x] Token.increaseApproval(...)
Controller.increaseApproval(...) that can only be called by TokenLedger.increaseApproval(...) that can only be called by Controller[x] Token.decreaseApproval(...)
Controller.decreaseApproval(...) that can only be called by TokenLedger.decreaseApproval(...) that can only be called by Controller[x] Token.burn(...)
Controller.burn(...) that can only be called by TokenLedger.burn(...) that can only be called by ControllerEach of the Token functions listed above can be executed by any account, but will only apply to the token balances the particular account
has the permission to operate on.
(c) BokkyPooBah / Bok Consulting Pty Ltd for Token Report - Oct 18 2017. The MIT Licence.