Dear members of the crypto community, I want to address you on behalf of the development team, with a proposal on the need to implement the standardization of the output of projects on the ICO.
A little bit about our vision:
Crypto community is a new state without obligations assigned to one person, but this is both a blessing and a curse of the community. Lack of commitment leads to the destruction of the foundations of the individual and the community itself. Unconditional ways regulating decentralized organizations are needed – our way most obvious in the given circumstances is to entrust regulation to the program code.
Code written in an open environment with the ability to easy and quick check by any member of the community. Our proposal concerns projects using the Ethereum platform for the primary release of tokens (public promises) for their projects. Smart contracts have reached such a level of trust and security that the community is already ready for such changes. We call on developers and all those who are not indifferent to join our appeal – projects that are necessary for the environment are sorely lacking, and in a heap of scam projects it is increasingly difficult to find them.
Our initiative concerns the standardization of the teams going through the ICO in the field of ensuring minimum guarantees for the safety of investors’ funds who believe in the project:
- At the start of pre-ICO team should have a contract for automatic assets transfer, that contains a written set of rules for early investors – not on towel, not in the speaking form, but written in the smart-contract. Otherwise, collected assets can just fall in the pockets of founders, or they can change rules of the game in the middle of act – there are many examples.
- The contract for pre-ICO should be a part of a bigger contract on ICO and do not be different tokens – it is unsafe form a standpoint of vulnerability and withdrawal of funds.
- The contract for pre-ICO, and then on ICO should have a lower and upper barrier – if it does not – the team does not know what it wants – just a scam.
- The contract for ICO should have escrow of the funds, received as a result of placement – it can be a frieze or multiSig with a voting condition. This will give you a guarantee against the expenditure of funds earlier than the team completed the previous stage.
- The contract should have indisputable return of funds condition, in case of not reaching the lower limit of the collected pool. It is in the contract and not in the white book, if it is not – move on, it’s just a scum.
- All contracts must be posted on GitHub, this will enable third-party developers to check the contract for the vulnerability, if the team has not taken care and before the ICO has not posted a bounty on the vulnerability.
- The contract must specify the conditions for the team and for the bounty’s for vulnerability.
- The contract must specify the conditions for not traded tokens – with clearly defined deadlines.
I suggest that all projects that are going out to the ICO in the near or not very short time receive free testing according to the list above. If you are not indifferent to the future of crypto-economics and the community as a whole, you will understand the necessity of this procedure – it does not take much time.
In case of refusal from voluntary passage, we with the team reserve the right to carry out this check independently and to put results in the general access.
Dear community members urge you to actively participate in this initiative – let us know about the projects that you wish to check – we will do this as quickly and correctly as possible, sending the result to the funders for correction.
In addition to protecting the interests of investors, our initiative will help the bounty program participants to more confidently offer their time because the conditions will be prescribed regardless of the co-owners, which means that the effectiveness and utility for the community and for you personally the projects that you promote will increase.
I want to explain why these points are highlighted by me as reference points and I’ll tell you what to look for if you decide to conduct the test yourself:
1. If the team accepts funds for a personal purse, this speaks at least about contempt for investors and the team’s lack of professionalism – as a consequence of the lack of competence in the technology in which they are trying to get funds, and as a maximum about the uncertainty about the viability of the idea – usually at this stage the team there is nothing more (and this is normal).
Gathering less than a minimum, the team is not limited to anything other than the standards of upbringing will leave at dawn waving the handle leaving investors and bounty team in despondency.
Collecting as much as you need does not interfere with the use of the upper scenario.
Inadequate evaluation of security measures taken to preserve the funds of early investors and bounty members.
The change in the price of the token relative to the initial promises – how will the same level of upbringing allow.
Conclusion: Automation of this stage will lead to at least a reduction in losses and as a maximum cool the heat of scammers.
2. If contract is on pre-ICO is part of the contract for ICO, look for the SaleAgent field in the body of the contract – that’s what it says about a single coin.
3 to 5.
Look for variables softcap and hardcap first talks about the lower border – the second one about their absence in ICO contracts and pre ICO speaks about the weak representation of the team’s goals and the necessary funds to achieve them.
For the automation of the return, the refund function responds – it is you who call it when the team did not collect the lower limit for the return of own funds. Note that the funds are returned less transaction cost.
6. Look for subcontracts with the names FREEZE and Multisig in the main contract.
The frieze contract describes the time of release of funds from the contract for the team to execute the next stage described in the white book for example, the team has 5 stages – according to the terms described the contract and releases the funds and transfers them as an option to the next contract called multisig. consensus by a majority vote – if the community considers the conditions described in the white paper at this stage to be fulfilled, it releases funds to the address of the funders.
The cycle is repeated as many times as the stages are stated in the frieze contract and, accordingly, in the white paper of the project.
On item 7 I will write a separate article.
8. Looking for a separate contract with the name Burn, it prescribes the conditions for the destruction of unsold tokens.
In the light of all of the above, I want to draw parallels with obstetrics and genetics. The products born today are mostly unsustainable due to underdevelopment of the skeletons of their bodies – protecting the interests of those who give their genes (money). Our initiative is similar to the manipulation of the uzi of a specialist who considers a fetus before his birth – ascertaining the degree of readiness of a product for life in a blockage environment. If we imagine that the community is a living organism, then a critical moment may come when the bodies that cease to work will destroy the whole organism – only through joint efforts can we stop this process.
In addition to the obvious advantages of our method of regulation – there is one more obvious at first glance – the stability and strengthening of the exchange rate against the currencies of the currencies – and this is another major problem of the crypto community – high volatility of the exchange rate. In view of the impossibility of rapid withdrawal of massive volumes from the crypt to the Fiat and the exact terms of the freeze, we forecast a stable growth of the Ethereum course in the long term and these leaps will become more obvious.