Every day more than 5 contracts (including test net contracts) are created on our platform. The safety of smart contracts is one of the key factors when they are created. Every contract, created on our platform is tested automatically (for example, more than 40 individual tests are launched just for Crowdsale contract).
Despite this fact, many clients prefer to use specialized companies for external audit. We respect that but as we said we run a lot of tests on every contract in order to make sure that it’s totally secured.
Today we’ll analyze one of these audits (https://docs.google.com/document/d/1ZfE347AfnULQ23VIwPlKE9RIiXKCbu4PSU0uNMy5BL8/edit?usp=sharing)
and comment all notes. However, we notice, that there are no any critical issues in the contract code, our platform is safe and our contracts are secure.
Here are our developers comments on every point in the audit.
1. The ^ symbol allows the use of compilers from the specified version (0.4.23) to 0.4.xx. But if you try to compile the code with a compiler of version 0.5.0, nothing will compile. It is assumed that to version 0.5.0 there will be no major changes. So now using ^ is totally safe.
2. We are trying to make our service more user-friendly.
It is inconvenient for a user to specify the block number, so we give the user the opportunity to specify a Start date and Finish date instead. These are identical things.
3. This situation is impossible since the contracts that are created are generated from templates. Before forming the final code, all values are checked for a valid range, which excludes the assumption of incorrect values.
4. This contract is generated without “Amount bonus”, so the parameter is not used.
5. The function wallet. transfer automatically defaults to the call of 2300 gas, which will not allow you to do anything else besides transferring money.
This solution is implemented by OpenZeppelin.
6. The token contract has a “burn” function.
Since tokens are created during the investment, all unsold tokens will not be created so there is no need to burn tokens.
7. In this contract, the function Changing dates is implemented, which allows, if necessary, to suspend the contract.
This is an additional feature, implemented for the convenience of the client. It should also be understood that any additional contract code increases the risk of an error. We care about the security of our contracts, so we write the minimum code necessary to implement the function.
8. This implementation provides the ability to freeze tokens. Using assembly is minimal and justified by a task that can only be implemented with assembly. The risk is considered, and the code is checked.
9. The OpenZeppelin library is used while connecting to the official repository.
10. The remark is not concretized.
11. These two functions are provided by the standard implementation of OpenZeppelin. Elimination of these functions is not advisable and will require profound changes in the contract that may affect security.
12. The presence of indentation is due to the use of the template.
13. Updating the compiler on the platform is performed after its reliability is repeatedly tested on the test server.
However, this report does not contain any criticisms requiring corrections.
Audit companies or developers who want to check our code are always Welcome!
MyWish is ready to pay for every found mistake.
Thank you for being here!
