The inSession state variable remains true indefinitely after the first session starts, preventing new enrollments and subsequent sessions. This violates the protocol’s intended lifecycle, where sessions should conclude after 4 weeks, enabling upgrades and new enrollments.
inSession State Variable: Never reset to false after a session ends.
startSession Function: Blocked by the notYetInSession modifier once inSession is true.
graduateAndUpgrade Function: Fails to reset inSession during upgrades.
Session Lifecycle Flaw:
When startSession is called, inSession is set to true and sessionEnd is set to block.timestamp + 4 weeks.
After sessionEnd passes, the contract logic does not update inSession to false.
The notYetInSession modifier in startSession permanently blocks new sessions because inSession remains true.
Upgrade Process Impact:
The graduateAndUpgrade function is designed to upgrade the system but does not reset inSession.
Post-upgrade, inSession stays true, preventing new enrollments (as enroll requires notYetInSession).
Critical Protocol Halting:
New Enrollments Blocked: Students cannot enroll after the first session ends.
New Sessions Unstartable: The principal cannot initiate new sessions, freezing the protocol.
Financial Loss: Stagnant protocol loses utility, potentially causing reputational and monetary harm.
inSession Based on TimeModify inSession to be dynamically checked against sessionEnd:
inSession During UpgradesUpdate graduateAndUpgrade to end the session:
Introduce a guarded function to reset the session:
`graduateAndUpgrade()` can be called successfully even when the school session has not ended
`graduateAndUpgrade()` can be called successfully even when the school session has not ended
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.