Beginner FriendlyFoundry
100 EXP
View results
Submission Details
Severity: medium
Invalid

Centralization and flexibility Issues

Summary

The Dapp is higly centralized with no flexibility in design

Vulnerability Details

  • lack of design flexibility:- on the off-chance that Ivan(the orgnizer and deployer)'s wallet gets hacked and hijacked, this leads to all funds in the ThePredicter.sol contract being lost forever because there's no way to withdraw the funds or transfer control of the ThePredicter.sol and scoreBoard.sol contracts to another wallet or smart contract.

  • Centralization issues:. Because Ivan(the orgnizer) said he's trustworthy doesn't mean ALL the Users have to trust him. in fact the other 14 that are not his friends may not trust him and this may lead to low revenue for the dapp as per predictionFee and even entryFee. this is because some of the 14 others may not be interested in predicting the matches since they are not sure if Ivan may switch thePredicter or call withdrawPredictionFees and run away with their funds at anytime since the setThePredicter lets him switch thePredicter at anytime. Worse still, the withdrawPredictionFees lets him withdraw all entryFee at anytime even before the matches start .

  • in the event that Ivan's wallet is compromised or lost and the 9th match result can't be updated in scoreBoard.sol, all reward funds(predictionFees) will be stuck and nobody will be able to claim reward either.

Impact

The primary purpose of buiding the Dapp may not be achieved due to little or low revenue and in worse case loss of all funds generated.

Tools Used

  • Manual review

  • Reading the Dapp's documentation

Recommendations

  • Use a multisig wallet for withdrawal of the funds meant for hall. some of Ivanis friends can be signatory to the wallet.

  • Using factory contract, deploy both contracts(scoreBoard.sol , ThePredicter.sol) and call the setThePredicter function immediately after deployments all in a single function. Once the thePredicter is set, setThePredicter function should not be callable again.

  • Ivan should not be the only one to update results. the protocol can either use a trusted oracle like Chainlink OR any other player should be able to update result after which majority of Predicters of that match will vote to confirm the result before it's used to calculate scores

Updates

Lead Judging Commences

NightHawK Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.