I want to officially request a pause on this course of action.
I understand that everyone who has had their hand in this particular project is ready to get this product delivered to the the ENS community and the greater cryptocurrency ecosystem. I am aware that there has been a lot of pressure from the community to deploy these contracts.
A ‘bug bash’ that is open to the public to test for vulnerabilities is a good thing and I am all for it 100%.
Please take no offense. The video is great but we should provide more direction to the community. This, as of now is an open invite and dare to any hacker of all hats to attack all official components of ENS to include but not limited to ens.domains web host, subdomains, it’s directory, files, or subsequently any link the data a crawler can find at any depth, etc. We should caution this as implications of a trigger happy hacker could disrupt the normal everyday operation of the live systems. We do not want that to happen.
There needs to be a clear outline that provides explicit guidance in a bug bash ‘event’. There is no scope or context about what is within the bounds of any testing by a user, tool or third party service.
//Define the scope of the bug bash The scope of the bug bash should be clearly defined to specify which parts of the web application and contracts are within the bug bash’s scope and which are not. This helps to avoid misunderstandings between ENS Labs, ENS DAO, the person(s) reviewing and the participants
//Set the rules and guidelines: The rules and guidelines establish the framework for the bug bash, including the rewards system, submission protocol, and a timeline. This helps to ensure that participants understand the parameters and expectations.It is important to for participants to not over extend their work by doing unnecessary tasks that may or may not help the overall outcome.
//Provide feedback to participants about their submissions: It is important to provide timely and comprehensive feedback to bug bashers on the status of their submissions, including whether their submission is eligible, accepted, rejected, or needs further clarification.
//Fix bugs : Once bugs have been identified, they must be fixed by updating smart contracts, amending web application code, or securing any underlying infrastructure.
//Distribute rewards to eligible participoants Once bugs have been fixed, rewards should be distributed to the submitters who identified them, which incentivizes talented individuals to return when development warrants the need
After all is said and done, the deploying teamshould convene and learn from the process to identify areas for improvement in future bug bashes. The bug bash process should be reviewed to identify areas of improvement, increasing or decreasing the scope, evaluating the fairness of rewards or providing more comprehensive feedback to those who participate.