SMART CONTRACT SECURITY AUDIT: TriForce
TriForce Tokens is a decentralized platform which makes use of blockchain technology to provide users within the iGaming community with decentralized P2P trading, anti-piracy protection, and the world’s first honorary rewards system. TriForce tokens follow three foundations of the technology i.e. Revenue Generation, Players and Developers Protection and Community Collaboration.
The network will strive to build community collaboration amongst players, whilst encouraging them to work together and reward one another.
Existing loopholes in iGaming ecosystem:
Problems for the Player
The gamers hoard reward points in terms of tokens which cannot be used in any other gaming platform, making it complicated. Moreover, sharing critical banking details put the players at a risk of being hacked, which cause financial loss and brand disloyalty. It is possible for hackers to insert themselves into the middle of the process where they can inject malicious commands and also make the use of updater to hijack the gaming machines. The multiple players in a gaming matrix do not have room to interact and play apace one game, therefore, cross-platform play is not facilitated making it a major concern among the gamers.
Problems for the Developer
At present, solutions to support the digital monetization and online growth strategies is scarce. Since more than the quarter revenue is shared with the developers, this adds up to become the biggest concern. Revenue management in the existing gaming system works like a Sloth, making it difficult to maintain close relationships with end consumers. The likelihood of piracy in iGaming industry equates to a reduction in game sales thereby impacting the overall revenue.
The TriForce Solution
With the use of TriForce Tokens, developers will once again increase their revenues and margins further allowing innovation and implementation of new thoughts. TriForce also intends to minimize the price to a manageable level and therefore improving the player’s gaming experience and by providing lucrative solutions to all the parties involved in the network. The blockchain technology bridges the gap and fills the loopholes in the existing iGaming landscape. This will likewise grow consumer relationships across properties and platforms and facilitates a direct developer-to-player channel by addressing the major concerns of both the parties.
Procedures
Techracers Team was approached to access the TriToken Smart Contract and pinpoint the vulnerabilities along with the potential threats. The major task was to discover and outline security issues in the Smart Contracts of the TriForce platform. We used several publicly available automated Solidity analysis tools and manually checked for vulnerabilities further.
Below is our assessment and recommendations:
Style Guide Violations
Not necessary to resolve but increase readability and enforces style guide standards accepted by the global community. An example image from the contracts has been added for each violation but similar violations can be cited in many contracts.
1.Usage of obsolete pragma versions of solidity instead of the latest stable one (0.4.18).
2.It is a standard practice to use the same pragma version throughout the contracts.
3.Pragma should be locked before deployment in every contract. (ref) (For example, 0.4.18 is locked whereas ^0.4.18 is not).
4.While declaring a function there should be a space between “)” and “{”.
5.Visibility of all functions should be specified, failing which it is defaulted to ‘public’. (ref)
6.Top level declarations in solidity should have two blank lines before them. (ref)
7.The default value for a bool variable is false so there is no need to initialize it. (ref)
8.There should be a space between if and (). (ref)
9.Two spaces have been used for indentation in almost all contracts, instead four spaces are recommended per indentation level. (ref)
10.Line length should be restricted to 120 characters.
11.Throw is deprecated in favour of revert(), require and assert(). It will be removed in future.
12.String Literals must be quoted with “double quotes” only. Including imports. (ref)
13.Function order is incorrect at multiple instances within the contracts, the correct order is as follows: (ref)
– Constructor
– Fallback function (if exists)
– External
– Public
– Internal
– Private
14.There should be a single space before a function. (ref)
15. Function with wrong modifiers present within contracts, currently solidity does not enforce modifier types, but it is a wrong practise. For instance the following function is marked constant, though it is updating a state variable totalSupply.
16.Confusing parameter and function names are present within contracts, same names can shadow a previous declaration, as in the example shown below, isAdmin is both a return type and a function name:
17. Unused parameters are present inside various functions like in the following example _cap parameter was never used.
Automated Testing:
Mythril:
Mythril displays the following two concerns for the audited contracts:
- A possible Integer underflow exists in function transferFrom.
2.A possible Integer underflow exists in function transfer.
Securify:
- Force.sol:
2.TriController.sol:
2.TriForceNetworkCrowdsale.sol:
Oyente:
- WhiteList.sol:
2.TriForceNetworkCrowdsale.sol:
3.RefundVault.sol:
4.Force.sol:
5.Token.sol:
6.SimpleControl.sol:
7.DataManager.sol:
8. DataCentre.sol:
9. CrowdsaleControl.sol:
10.Controller.sol:
11. TriController.sol:
Manual Testing
- TriForceNetworkCrowdsale.sol
- There is no need for WhitelistedCrowdsale contract to inherit Crowdsale contract. Everything will work fine even without it.
- In whitelist contract which is being used in this crowdsale 2 more functions can be added which will add or remove the whitelisted addresses in bulk. It should also fire events when any whitelisted address is added or removed so that, later if we want to find the list of all addresses who have been whitelisted then we cannot get this list from a mapping.
- An interface of whitelist contract can be included which only has one function isWhitelisted(), this will slilghtly reduce gas at the time of deployment of TriForceNetworkCrowdsale.sol.
- In refundvault contract being used in this crowdsale we can fire an event when deposit function is called.
- Selfdestruct functionality can be added in the refund vault contract so that all the ethers in the vault can be transferred to a safe address in case of any bug.
- TriController.sol
- Token contract is being used in this TriController contract. We need to call mint() and mintToggle() functions of Token contract deployed separately. To achieve this we need not to import all the contracts we can create a interface of functions that we are going to use. This will slightly reduce the gas consumed at time of deployment.
- Force.sol Everything looks good. All ERC20 and ERC223 functions working fine.
Summary
All above points are suggestions to optimize the code. Overall the code looks impeccable and it is designed in a way which makes it easily upgradable. If any bugs are encountered all the functions can be paused for everyone (except for admins) and then the controller contract will be killed and a new controller can be set.
CONCLUSION
The problems that we have found in TriForce Tokens are described above. We successfully scanned TriForce’s Smart Contracts for commonly known and more specific vulnerabilities. We used publicly available automated Solidity analysis tools which manually analyzed the contracts. Further, the Smart Contracts logic was checked and the analysis displayed high code quality and security of the project. Techracer’s smart contract security audit services successfully addressed commonly known vulnerabilities and the issues were fixed to make the Smart Contracts completely secure.
The importance of security of the code cannot be overstated, especially when we consider auditing your smart contracts. It is perhaps the only way to ensure that your smart contract will do as it has been programmed to do. Preparing a smart contract is not just about writing impeccable codes that no hackers can get, but it should also consider prevention against bugs.
