Xtock Token security record

As it presently is constructed, the contract is vulnerable to the allowance double-spend exploit, as with other ERC20 tokens. An example of an exploit goes as follows: 1. Alice allows Bob to transfer N amount of Alice's tokens (N>0) by calling the approve() method on Token smart contract (passing Bob's address and N as method arguments) 2. After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls the approve() method again, this time passing Bob's address and M as method arguments 3. Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls the transferFrom() method to transfer N Alice's tokens somewhere 4. If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain an ability to transfer another M tokens 5. Before Alice notices any irregularities, Bob calls transferFrom() method again, this time to transfer M Alice's tokens. The exploit (as described above) is mitigated through use of functions that increase/decrease the allowance relative to its current value, such as increaseAllowance() and decreaseAllowance(). Pending community agreement on an ERC standard that would protect against this exploit, we recommend that developers of applications dependent on approve() / transferFrom() should keep in mind that they have to set allowance to 0 first and verify if it was used before setting the new value. Teams who decide to wait for such a standard should make these recommendations to app developers who work with their token contract.

The owner can enable and disable transfer-related functionalities at will through the use of the isNotFrozen() and isNotFrozenFrom() modifier, or by setting a sufficiently large timestamp for a time locked account. While not necessarily a vulnerability, if the contract owner's private key is compromised or the owner becomes malicious, then token holders may be unable to transfer their tokens. This issue is magnified in the case of time locking as it can be performed by all super admins, not only the contract owner. In the spirit of decentralization, we recommend taking away these functionalities from the contract owner and the super admins. The Xtock team has communicated to Quantstamp that the ability to freeze the token and specific accounts is implemented for AML purposes. This should also be communicated clearly to token holders upfront.

The Xtock token contract embeds contract interfaces and methods from the OpenZeppelin library. The embedding happens through the clone-and-own approach, where the original code is copied and adjusted. From the development perspective, it is beneficial as it reduces the amount of effort. However, from the security perspective, it involves some risks as the source may not follow the best practices, may contain a security vulnerability, or may include intentionally or unintentionally modified upstream libraries. As opposed to the clone-and-own approach, a good industry practice is using the Truffle framework for managing library dependencies. This eliminates the risk of the clone-and-own based approaches yet allows for following best practices, such as, using libraries.