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.