Patientory PTOY Logo

Security Audit for Patientory (PTOY) Token ICO

Reading Time: 3 minutes



CoinFabrik smart contract audit‘s team was hired to audit contracts written by TokenMarket for the PTOY Token ICO. The result of this security review is reflected in this document.

Audited Files

The contracts we audited are hosted at Github repository:


Commit hash f968cffe1abf4a3d96d6705ec1befd6cfec13ae3.

Vulnerabilities Found

Short Address Attack

The version reviewed of contract StandardToken which implements transferFrom and approve are not protected against the recently found vulnerability “ERC20 Short Address Attack”  (

We should note that the method transfer is protected for this attack.

They should verify the payload size that matches the size of the function parameters:

Should add onlyPayloadSize modifier to transferFrom and approve functions:

Refund tokens

The CrowdsaleToken does not provide a method to refund received tokens. There are cases when a user by mistake has sent token to a contract address. If the contract does not provide a method to recover those tokens, those tokens are held indefinitely by the contract, and cannot be retrieved and are effectively lost.

The following implementation allows the owner to return tokens to a specified address:


Functions transfer, transferFrom and approve return a boolean value. They use safeAdd and safeSub which throws on error conditions. This is inconsistent with the boolean return value, they should return false on failure. Also, ReleasableToken.sol uses modifier canTransfer which throws on error.

Solidity Version

MintableToken.sol v0.4.6
CrowdsaleToken.sol v0.4.8
ReleasableToken.sol v0.4.8
UpgradeableToken.sol v0.4.8

We recommend using v0.4.11 or above since these versions are vulnerable to ConstantOptimizerSubtraction (low-severity)

Duplicated code (minor)

There are two implementations of secure mathematical operations, one in the SafeMath contract and another in the SafeMathLib library.

Having duplicated code perform the same operation it increases the cost of the deployment of the contract unnecessarily. Duplicated code might cause subtle bugs that are hard to debug and from an engineering perspective it increases the burden of testing and reviewing.

In this contract the functionality is almost identical and should not cause problems, beyond an increase in deployment costs.

Implemented improvements

Protection for double spend on approval

Tokens that implement the standard ERC20 are subject to a double spend attack when the user A approves a limit to user B by mistake, and tries to fix calling again with a new limit. If the user B retrieves the tokens between calls it will be allowed another extraction.

The contract code provides a protection against this attack. To modify an address extraction limit it first should be reset to zero. It also provides two methods addApproval and subApproval, that are not part of the ERC20 standard, that provide functionality to alter the limit without the risk of the double spend attack.

Short address attack

The methods transfer, addApproval, and subApproval are reasonably protected against the double spend attack.