# NoCode Tool for (SubDAO)-Spells ## Disclaimers to put this text into the right perspective: - This is just a quick draft to get across the core idea and how we derived it. I am not a fan of doing a lot of work that can become redundant if the core idea is not well received - While our work for Maker so far was very niche around one product suite, our non-Maker work at Sidestream, across all kinds of industries, is similar to what I am proposing in the below text: We take an outside perspective and respectfully challenge how technical incumbents do their current work by proposing something different ## Background I think most of us are aligned that operative SC-work needs to have open access for more developers to contribute while mitgrating the risks through sandboxes, good parameters etc, so that: - Decentralization and resilience is increased - SubDAOs can operate quickly - Endgame can scale without being bottlenecked by operative work The current approach of opening access to SC-work is that some engineers are actively working on taking over operative SC-work from PE, especially Spells. Spells are rather easy SC-work (more configuration, less novel development) and regularly needed. However, I see a few (future) problems with this approach: - The current way PE does spells is quite know-how heavy. It works (well enough) if you know the craft, but getting there takes a long time --> requires high education investment - The current way PE does spells, requires good engineers, while the tasks themselves are not super exciting to do in the long term (repeatable configuration rather than novel development). I'd be concerned with retaining the trained developers over a long time. Moving them into EAs will just move the retention topic under another umbrella rather than solve it So I suggest to adjust the approach of opening access to SC-work: We can strive to make the majority of repetitive, operative SC-work executable for **everyone** inside a SubDAO. Just like early stage Startup founders these days don't require System Administrators or DevOps people for the majority of their Infrastructure work, because the majority of things they can easily configure in a AWS UI themself. Based on [this](https://docs.google.com/spreadsheets/d/1dV9HflyvD4dvI77O8QnfcbSH0kZ5jBVVu_nQLoyoxqk/edit#gid=1889204713) use case overview from Miguel, it seems that many spells will be very standard. Just for the less-standard work there should be expert EAs to contract by SubDAos. This remaining EA work is then more challenging and diverse and therefore more fitting for good developers ## Solution: How to make SC-work executable for everyone? Create an Open Source NoCode Tool that enables everyone to create typical Spells via a User Interface. Under the hood the tool will include a static, easy to read and maintain rule set (e.g. a large JSON file) of all things per contract type that make a valid contract. The rule set would be informed by and continuously updated in accordance with the evolution of the GS Framework. Many of the current validity checks in spell development and testing (e.g. is the address valid and the right one) will be automated inside the tool. Therefore, everyone can be sure. that a spell produced by the Tool will already be in accordance with all rules and checks. I imagine that in the end the tool will automatically open a Pull Request with the produced code (if needed, we can think about some way of validation so that everyone can be sure the code is really according to the rules and not corrupted on the way from Tool to Pull Request). With the Code in the Pull Request one can either directly submit the Spell, or someone does a review or if some non-standard things are required an EA can be contracted to keep working with the Pull Request. The diagram below is an extension of the digram from the Endgame Products Alignment call on 13th December 2022. The blue parts are added with the suggested Tool. ![](https://i.imgur.com/2uIdHmr.png) The MVP would be just a tool that can produce one type of Spell. If this is considered useful for that particular case, we can keep expanding with more spells. ### Where this could go This part I am less certain about: The below diagram shows a potential longer term evolution of the tool with several new components: - Rule Set that is informed by GS Framework (similar to MVP) - NoCode like UI for “everyone” to create smart contracts (similar to MVP but just covering more use cases than spell creation e.g. producing VaultAdapters, D3MAdapters) - Marketplace for complex SC development tasks: SubDaos can specify requirements, EAs compete on taking over tasks, the whole process facilated and monitored via the tool - Security Review: GS Tribunal (or someone else)is able to do final Pull Request Reviews on security-related topics. The process is facilitated via the tool for full end-to-end transparency on the development process ![](https://i.imgur.com/kcSFNnu.png) ![](https://i.imgur.com/d9VkqNy.png) ## What if we don't get user adoption for the tool? We might learn that it is easier to educate and retain many Mini PE teams and let them just do all the work in a similar way as PE does for MakerCore. The tool would then not be needed. I think this is unlikely, but even then I think that working on this product is beneficial: Having to codify all options, rules and checks for different contract types will force us to go very thoroughly about extracting all these requirements from the brains of PE (and potentially challenge some of them on the way). Every option, rule and check that we codify should be free of doubt to every relevant developer. So in the end we should have a better rule set than if we just start developing a very long (theoretical) documentation that every developer has to stick to. ## Next Steps If the idea is at least considered 'worth to explore further', I'd spend some time to validate a few technical blockers and then scope the MVP. Then we can decide together, whether it is worth our time or whether other things have a better expected ROI.