Hey 1Hive Dev team, I am taking up the responsibility of documenting a framework/ process that will provide some guidelines for future and current developers that will be using 1Hive as a launch pad after this discussion with Luke on the forum https://forum.1hive.org/t/alvin-and-the-dripp-ocalypse/3757/30.
For the moment my plan of action is to collate inputs from various Devs on their own routine that is followed when developing, reviewing, testing and post-release of a smart contract. I then intend to put all the feedback I get from the various Devs into a document format with separate sections addressing each stage of dev from concept to release. I would also ideally like to come up with some sort of a pre-release check list which can be used as a quality control process and ensure we do not have more dripp-apocalypses.
I have never really developed a smart contract so I may not understand the intricacies and so will lean on your collective experience here to see if I can come up with something that will be useful long term for 1Hive. I would really like all devs within 1Hive to may be give a few minutes of your time to comment and provide me any inputs that you think will help me in getting this framework completed.
I have prepared a questionnaire that I hope will help flush out some of the information I need:
- What are some current processes that are followed when starting development of a smart contract?
- Is there a list a libraries that are recommended to be used e.g OpenZepplin?
- Is there a list of simple checks like āFunctions that do x need to be declared privateā etc.
- Is there an established process to ensure that each iteration of code goes through a review? Do we have an established team that does reviews of code?
- Do you know if there is a list of lessons learnt from previous hacks that have been collated and published in one place? As each hackās reason would have been a specific part of vulnerable code that allowed the exploit to happen. I assume if these can be collated it would be like a checklist that could be used to by each new dev to avoid known pitfalls.
- Could we brainstorm and get a list of things that must be checked during dev and prior to release of SC?
- What about pre-release checks - i.e where the keys are stored for minting of tokens, who deploys the contract, who checks prior to deployment, etc.
I am open to any sort of comment/ criticism on this issue and my approach to documenting the framework. So please be honest and give any feedback necessary to steer me in the right direction.
Tagging people I know that could give me feedback - @lkngtn @anisoptera @Monstrosity @metaverde @luigy @FriedRengi @willjgriff @fabriv