Rock Paper Scissors

First Flight #38
Beginner FriendlySolidity
100 EXP
View results
Submission Details
Severity: high
Invalid

πŸ”Ž Centralization Risks vs. Decentralization Claims in RockPaperScissors DApp

πŸ”Ž Centralization Risks vs. Decentralization Claims in RockPaperScissors DApp

πŸ“Š Summary

The RockPaperScissors DApp advertises itself as a "fully decentralized implementation" of the classic Rock-Paper-Scissors game on Ethereum. However, upon reviewing the actual implementation and its security structure, multiple design elements contradict this decentralization claim, introducing centralization risks that should be acknowledged and addressed.


πŸ”Ž Observed Claim

"Rock Paper Scissors DApp is a fully decentralized implementation of the classic Rock Paper Scissors game on Ethereum."


⚠️ Technical Findings That Contradict This Claim

1. Ownable Usage in WinningToken.sol Contract

  • The WinningToken.sol contract inherits from OpenZeppelin's Ownable, and the mint() function is restricted via onlyOwner.

  • This means that the entity which deployed the contract (typically the RockPaperScissors.sol contract or its deployer) retains full minting control.

  • This introduces a central point of control that contradicts decentralization.

2. setAdmin() Function in RockPaperScissors.sol

  • Allows the current admin (owner) to change the adminAddress arbitrarily.

  • No on-chain governance or access control layers (e.g., multi-sig or timelock).

  • A malicious or compromised admin could assign themselves or another address and steal accumulated protocol fees or interfere with game settings.

  • This was verified and demonstrated through a valid Proof-of-Concept exploit.

3. No Use of On-Chain Governance or Decentralized Access Control

  • Contracts lack role-based permissioning via AccessControl.

  • No usage of DAOs, community voting, or multisig wallets.

  • Critical protocol-level actions (minting tokens, withdrawing fees, changing admin) are fully centralized.


πŸ”§ Real-World Impact of Centralization

  • Trust dependency: Users must blindly trust that the deployer/admin will not abuse privileges.

  • Token issuance risk: Unlimited minting of WinningToken is possible if owner privileges are abused.

  • Fee control risk: Protocol fees held on contract can be redirected to an attacker via admin key compromise.


πŸ” Recommendations

To align the implementation with the decentralization claim:

  1. ⛏ Remove Ownable from WinningToken.sol or replace with AccessControl and restrict mint() to RockPaperScissors.sol only.

  2. πŸ” Harden admin management in RockPaperScissors.sol:

    • Introduce a multi-signature wallet (e.g., Gnosis Safe)

    • Or replace setAdmin() with time-locked governance proposals.

  3. βš–οΈ Introduce max supply for WinningToken.sol to mitigate infinite inflation.

  4. 🫠 Document all centralized points clearly if temporary or introduce transition plans to decentralize.


πŸ“„ Conclusion

While the game logic and user flow are decentralized in spirit, the underlying administrative and token mechanics introduce central points of failure. This undermines the protocol’s claim of being "fully decentralized" and should be addressed transparently for users and security auditors alike.

πŸ“„ Tool Used

Aderyn - Solidity Security Extension

Updates

Appeal created

m3dython Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Design choice
Assigned finding tags:

Owner is Trusted

m3dython Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Design choice
Assigned finding tags:

Owner is Trusted

Support

FAQs

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