The FestivalPass
contract sets the beatToken
address only in the constructor with no mechanism to update it later. If the contract is deployed with an incorrect BeatToken address (including address(0)
or a non-existent contract), the entire FestivalPass contract becomes permanently unusable, requiring full redeployment and loss of all existing state.
The BeatToken address is set immutably in the constructor with no update function:
Key issues:
No validation that _beatToken
is a valid contract address
No setBeatToken()
function to correct deployment mistakes
Contract becomes permanently broken if wrong address is used
Likelihood: Low - Deployment mistakes can happen, especially in complex multi-contract deployments.
Impact: Medium - Entire contract becomes unusable, requiring redeployment and loss of state, but no funds are directly at risk.
Low-Medium severity because:
Contract becomes completely unusable for core functionality (attending performances, redeeming memorabilia)
Users can buy passes but cannot earn BEAT tokens or redeem memorabilia
Requires full redeployment, losing all existing state (passes sold, performances created, etc.)
High operational disruption but funds can be withdrawn via withdraw()
function
This test demonstrates how a wrong BeatToken address breaks the entire contract:
Option 1: Add constructor validation and setter function:
Option 2: Use a deployment script with verification:
This ensures the contract can recover from deployment mistakes and maintains operational continuity.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.