Lessons learned and RAID staked.
After a trialling Rite of Moloch in a closed alpha one year ago, the latest onboarding cohort at RaidGuild Season VI granted us the opportunity to launch ROM as a closed beta. We built an app where everyone, who successfully participated in the cohort can claim back their funds, but lessons learned are plenty. It is hard for DAOs to manage its members.
The launch of ROM proved this once again. While we are building ROM to bring ownership to individual contributors, we lost valuable time to give cohort members pretext due to lacking ownership of the decision which logo to use for the cohort. This caveat gave us a bumpy launch and highlighted once again the raison d’être for ROM and is a great start to dive into the details of our launch.
Organisation is hard - ROM makes it easy.
Defining responsibilities is easy if you are in the same line of work, in the same office, and can split tasks. This undertaking becomes increasingly difficult, the fewer touch points are between collaborators. Now the launch of ROM required the ROM team to align with the program managers of Season VI at RaidGuild and the participants of Cohort Season VI DAO.
We learned that DAOing needs to be learned and ROM, could have been part of this educational journey. This would have led to a timelier deployment and a proper introduction to ROM for its users. As ROM has interfaces that are Web2-ready, such as the image hosting, many variables had to be accounted for by administrators. We then accidentally deployed the cohort twice and lost one cohort member, who staked in the deprecated cohort due to the permissionless nature of ROM.
If ROM natively supported single member cohorts or a fast-tracked cohort deployment, ROM could have been a way to signal responsibilities rather than distributing tasks. Our low barriers to entry for administrators and participants produced a coordination failure and early users were left confused. In the future, we should smoothen launch cycles and focus on the core USP of bringing clear instructions for collaboration to DAO contributors. It is not just about a logo, but the entire lifecycle management needs to be planned and owned. Thus, administrators may need to be introduced prior to the actual deployment.
Connecting to DAOHaus.
We then asked ourselves who are the individuals and entities owning the process behind ROM. We made the experience that ROM was not configured to allow tributes to DAOHaus v.3 DAOs, because previously no DAO in charge of allowing our Shaman Manager contracts at ROM used tributes. We were left with an undeployable cohort unless we disabled the Shaman functionality through the selector on the frontend. This meant removing the option to render Season VI’s ROM cohort as single use, which limited the scope of our beta launch. To go ahead with the deployment itself we weighted into the notion that even the Season VI DAO may only be temporary. Despite the delays and unclear responsibilities ROM went live and participants started staking.
With the cohort coming to an end, it becomes clear that ownership implemented through an integration with DAOHaus may not suffice to deploy ROM in multifaceted use cases. Furthermore, the chasm between cohort administrators’ actions and a formalised organisational structure of DAOs creates uncertainty because ROM deployments become subject to principal-agent dilemmas and information asymmetry. In the next iteration, success criteria must be extended beyond DAOHaus shares to provide users with greater flexibility and enable ROM deployments on other EVM-compatible networks.
We better get UX right.
WEI is one of the foundational variables of programming in Solidity, yet it produces friction for frontend development and users, if not abstracted away properly. This has caused our beta launch participants to flag a couple of UX issues, where WEI was displayed on the frontend and inputs where inconsistently requiring WEI and unit amounts to be inserted. Hence, we had to patch alignment bugs and faulty input descriptors in a hot fix. We could have avoided the tensions by more thoroughly quality testing the application ahead of launch, however, our thorough alignment with agile development enabled us to save cost and improve the application mid-launch.
It is still unfortunate that these issues negatively impacted user experience, where even small shortcomings like the need to prompt a hard refresh between asset approval and staking caused unnecessary friction. With a whitelabel interface on the roadmap, we better get UX right in the near-term future.
New horizons and novel success criteria
What is next then for ROM? ROM ought to find market traction and the product-market fit must be validated. This prompts us to work on additional features, such as extending success criteria for reclaiming stakes. Additionally, we are evaluating the possibilities to make ROM available on other networks to maximise our market exposure. These strategic extensions are coupled with work to improve the user experience, namely, whitelabelling ROM for better accessibility. Lastly, we obviously must fix miscellaneous bugs that were surfaced during launch and improve the signalling around the management fee ROM collects for providing the service.
Overall, our beta launch was a success and taught us valuable lessons for planned development. Our team has conducted a retrospective and an updated version of the contracts is deployed shortly. We are looking optimistically enthusiastic in the future and are determined to bring ROM to the next level.