Sparkn

Summary

Project team explained that they started with less decentralized protocol like mix web2 and web3, centralized ownership that creates contests etc and hopefully will decentralize in future

Vulnerability Details

If the purpose of such guarded approach is to ensure safety of protocol it may as well implement some emergency features in case something happens e.g DOS, funds lost, funds stealing, injection of wrong winners etc. The project can implement Emergency control patterns such as Pause functionality to pause the creation contests, launch of proxies, distribution funds etc to protect its reputation, users, funds and functionality. It is already centralized and with good communication and onboarding users it can explain purpose of Pausability that it will be removed with time, sort of like guard rails

Impact

Without Pause functionality it puts the project at risk of not being able to intervene in the case of problems

Tools Used

Manual Analysis

Recommendations

It is recommended project implement one or more Emergency Patterns such as Pausability e.g inherit from OpenZepplin Pausable contracts and apply whenNotPaused modifier to critical functions