Framework/ Processes for development related swarms - Request for Feedback

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

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:

  1. What are some current processes that are followed when starting development of a smart contract?
  2. Is there a list a libraries that are recommended to be used e.g OpenZepplin?
  3. Is there a list of simple checks like ‘Functions that do x need to be declared private’ etc.
  4. 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?
  5. 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.
  6. Could we brainstorm and get a list of things that must be checked during dev and prior to release of SC?
  7. 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


I feel like in the absence of an audit we should at least have a panel at 1Hive that looks at the code, compares it to what it was cloned from if cloned, and looks at the tests/how it was tested.
Also, I may be in error, but it feels like anything that gets deployed in the defi world should be testnet deployed first.
I’m not a Solidity dev (yet), so I don’t want to suggest any specifics regarding hard and fast rules.
If we could get @willjgriff to run all would-be collaborators over the coals… respect Will.


Thanks meta… appreciate the feedback. I was also thinking that some sort of a diff tool to be used to highlight changes from standard libraries in the code which would ensure that focus time is spent on changes that are new. I have been asking the same question around other DeFI discords and mostly the suggestions I am getting is consistent - Use standard code from libraries such as open zepplin, study existing hacks and ensure previous vulnerabilities are plugged, review code thoroughly prior to any release, testing extensively if possible using a white hacker to actually stress test code.

I am not sure how we are set up in 1Hive for dev of SCs… but waiting for some senior devs to provide me comment and feedback so that I understand the current processes followed. I am really curious to know what type of stress tests and reviews our shiny new farming contracts go through taking into account that they may have a few million in AUM when they are fully deployed.

1 Like