What are Smart Contracts?
Self-executing contracts that contain and validate certain terms and conditions of agreement between sellers and buyers in the form of code are termed as Smart contracts. These line of codes containing the agreement once finalized, are stored on a decentralized blockchain network.
The need of smart contracts arises to build trust between unknown parties who are willing to sign an agreement without the involvement of a central authority of any external system. Transaction rendered in smart contracts are transparent as well as irreversible.
Smart contracts facilitate the exchange of money, property or anything valuable without the need of any middleman. They guarantee automation and transparency in online processes.With this, it becomes highly important to secure these contracts too.
What’s the need of Security Audit for Smart Contracts?
Since the agreements stored in smart contracts are of crucial importance for multiple parties involved, it’s necessary to secure these agreements from hackers via security audit. Every smart contract needs an audit in order to prevent issues like data loss, breaches and thefts.
There are certain advantages of Auditing Smart Contracts such as:
- Code optimization for running the code efficiently
- Authorization reinforcement
- Call methods on Smart Contract
How Techracers performs Smart Contract Security Audit?
The need of application security has increased with the introduction of Smart contracts. We help companies in creating compelling and secure Smart Contract codes.
We perform code audits for organizations by reviewing their smart contracts code and writing each and every issue detected in an actionable report. This includes potential code problems, security recommendations as well as general analysis.
After the complete analysis, our developers review claims and fix the application code using industry-standard security patterns and best practices.
Peculium Smart Contract Security Audit
Techracers Blockhchain team was given the task of performing the Peculium Smart Contract Security Audit. Peculium is a savings management platform that utilizes blockchain technology for savings management by deploying immutable smart contracts on Ethereum blockchain. It provides effective savings management solutions for individuals, brokers, and enterprises as per the underlying value of crypto-assets.
The code of Peculium smart contract is here- https://etherscan.io/address/0x53148bb4551707edf51a1e8d7a93698d18931225#code
Code references marked in PURPLE
- No ERC223 compatibility present inside contracts. Tokens get stuck in contracts UNKNOWINGLY when using ERC20. (ref)
- A lot of failed transactions on etherscan because of the require break in transfer function, as shown in the following snippet:
Why Users should be made aware of the require break, ‘Can only transfer after 24th January’, if they have a dapp or a newsletter. Unnecessary gas wastage for users.
- Similarly, for approve + transferFrom, users will have lots of failed transactions due to the require break similar to the one in point 2.
- SafeERC20 library imported but not used anywhere. This leads to unnecessary deployment gas costs. Following is the SafeERC20 library:
None of it’s functions are used but it is still inherited:
- In function approveAndCall, untrusted external calls to contracts are present, this should be explicitly labelled as untrusted i.e _spender should be marked as _untrustedRecipient instead of _spender.
- The code’s indentation is so bad it would be difficult to list all the violations made, this leads to very poor code readability. Please go through the Solidity’s official style guide and improve it.
- Function name freezeAccount(address target,bool canSell) is a misleading name, it should be updated to toggleAccountFreeze(address target,bool canSell),this is because owner can also unfreeze accounts using this function.
- Similarly, event FrozenFunds(address target, bool frozen) is also a misleading name, it should be updated because, bool frozen can also be false.
- now is used for time approximation within contracts, but block numbers are more accurate. You can ignore this recommendation if your functionality is not that time dependent.
- Should burn token be a public function? This will let anybody burn his own tokens.
- No need for the function getBlockTimestamp. The functionality to check it is already available and there are a lot of ways to do it.
- Misleading naming convention balancesCanSell.
- Improper commenting techniques used throughout the code.
- Pragma should be locked before deployment in every contract. (ref) (For example, 0.4.13 is locked whereas ^0.4.13 is not).
- sha3 has been deprecated in favour of keccak256.
- No address(0) check for input parameter- target, in function freezeAccount.
- No address(0) check for input parameter- _spender, in function approveAndCall.
- No check for _spender attribute to be a contract in function approveAndCall. Insted following function should be used:
- Following code can be used to introduce re-entrancy, though it will not be a problem right now because value is assigned directly, but that itself is wrong. Also did not find any receiveApproval function in the provided code, therefore cannot check it.
- _value has been directly assigned in allowed mapping, instead add function of safeMath library should be used. Why should we assign value directly, suppose a case where a user has allowed 1000 tokens, now he wants to add 500 more tokens to the value, upon calling approveAndCall function with 500, now the allowed mapping will be set to 500, instead of 1500 tokens.
- No check for msg.sender token balance before increasing allowed mapping in the following two functions.
- Too many failed transactions on etherscan.io due to the condition
I guess people are not aware about the condition.
- Integer underflow:
- Call with gas to dynamic address: