It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency,
since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site;
Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.
The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in -
your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.
We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency
so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.
How does #audit of a # smart_contract look like? Customers or young development teams frequently ask this question.
Below is an example of a real report on the audit of one of the contracts. Without names.
Feel free to adopt.
*** [Methodology of audit] The contract code is manually scanned for known vulnerabilities, logic errors, WhitePaper compliance. If necessary, unit tests are written for questionable moments.
*** Classification of identified problems
CRITICAL – the possibility of theft of the ether / tokens or their blocking without the possibility of restoring access or other loss of ether / tokens due to any party, for example, dividends.
SERIOUS – the possibility of violations of the contract, in which to restore its correct operation, it is necessary to modify the state of the contract manually or completely replace it.
WARNINGS – the possibility of violation of the planned logic of the contract or the possibility of organizing a DoS attack on the contract.
NOTES – all other remarks.
Identified problems
🔥 [CRITICAL] – None
❗ [SERIOUS] 1.
The technical characteristics of the token indicate that the token contract must have a “burning” function. This function is implemented, but you can only burn your own tokens. Judging by the technical characteristics (the remainder of unsold tokens can be manually “burned” at the end of all activities) there should be a function of burning tokens by the organizers. Thus, in the current version of the contract, unsold tokens will remain on the crowdsale contract without the possibility of withdrawal.
📣[WARNINGS]
1.
In the version of the StandardToken contract from the Zeppelin Solidity library, an error error was found https://github.com/OpenZeppelin/zeppelin-solidity/issues/375, which allows to generate a false event about the transfer to itself of any number of tokens, even exceeding the ones available.
2.
Probably, in the formula the excess division by 1 ETH. with the current formula, to set the price of the token to 1 dollar, you need to call the setRate method with the parameter 300 * 10 ^ 18. It is better to implement the rate without such a number of zeros, so that there are fewer opportunities to make a mistake.
3.
We also recommend adding an event:
Transfer (burner, 0, _value); in order for wallets, etherscan.io and other clients to see the fact of the balance change. Without this, many investors simply will not see their tokens in their wallets.
A similar problem exists in the token constructor,
, there should be added:
Transfer(0, ADDRESS_FOR_TOKENS, INITIAL_SUPPLY);
💡[NOTES]
1.
The latest version of the Zeppelin Solidity library is not used. Changes in the new version:
fixed a bug in the transferFrom function of the StandardToken contract (see p.1 of the warnings) In the functions of contracts explicitly specified visibility modifiers optimization in mul function from SafeMath, slightly reducing gas consumption in the contracts BasicToken, StandardToken, BurnableToken in the functions transfer, transferFrom and burn are added checks of input parameters that do not burn all gas in case of failure: a check for transfer to a zero contract and that the value for transfer / incineration is less than the balance and allowable for transfer amount.
The technical characteristics of the token indicate that the token contract must have such functions as “Transfer of owner rights” and “Are Ownable”. For a token contract, this is not done, but it may be necessary if the function of burning tokens in the token contract is added.
4.
In the mechanics of the contract, there is a reference to the “shelf life” of the contract (which is 365 days). This is not implemented.
5.
In the comments to those. the description is written, why the signature of three people of actions with contracts was not realized. Usually, to make these minuses irrelevant, they make it possible to perform actions that are not signed by all the owners. For example, signed by two owners of three.
There is no check for the amount of transmitted ETH, you can buy 0 tokens.
8.
Blanks ADDRESS_FOR_TOKENS, ADDRESS_FOR_ETH, START_DATETIME – bad practice, because will require code modification before deployment, which is fraught with errors.
9.
modifier onlyOwner is redundant inCrowdsale
10.
Pointless line. In addition, the default rate is 0 and its installation is not monitored before / during the beginning of crowdsale – this is fraught with the fact that if you forget or do not have time to install it, payments will pass for which 0 tokens will be credited.
It is necessary to specify in the instruction about the need to set the rate in this line before the contract is deployed and allocated visually.