The dealine_set flag is written once as false and never again, making the DeadlineAlreadySet check unreachable

Description

• The program deliberately encodes a one-shot rule for the campaign deadline: a dedicated boolean on the Fund account, a guard that rejects a second call, and a dedicated error variant for it. Once a deadline is announced, contributors should be able to rely on it — it defines when contributions close and when refunds open.

• The flag is initialised to false and never set to true by anything. set_deadline writes the new deadline and returns, leaving the flag exactly as it found it. The guard therefore never fires on any input, ErrorCode::DeadlineAlreadySet is unreachable code, and the deadline is freely rewritable for the entire life of the campaign.

The flag appears three times in the entire program, and exactly one of those is a write:

Both gates that depend on the deadline therefore sit under the creator's unilateral, repeatable control:

Two adjacent omissions in the same function compound it, and both survive the obvious fix of simply latching the flag:

• No bound on the value. set_deadline accepts any u64, including u64::MAX and any timestamp already in the past. There is no maximum campaign duration, so a deadline can be set that will never be reached.

• No ordering constraint. Nothing requires the deadline to be fixed before money arrives. The creator can let contributions accumulate while deadline == 0 — a state in which the fund advertises as maximally permissive, since line 29 admits every contribution and line 69 admits every refund — and only then call set_deadline(u64::MAX), closing the refund window on contributors who are already in. That sequence uses a single, first, entirely "legitimate" call, so latching the flag does not prevent it.

I am reporting these together with the dead guard rather than separately because they are one function, one intent, and one patch: the whole of set_deadline's validation is missing, not one line of it.

Why this is a defect and not a creator privilege

Ordinarily "the creator changes a parameter on their own campaign" is designed behaviour and not a finding. That defence does not apply here, because the developer explicitly attempted to forbid it: the dealine_set field exists solely for this restriction, the guard at line 57 exists solely to enforce it, and DeadlineAlreadySet at line 198 exists solely to report it. All three are present and none of them work. This is an invariant the program tries to enforce and fails to, which is a broken check rather than an intentional permission.

fund_create is also permissionless (lines 12-22) — any signer can be a creator — so the actor holding this unintended power is an arbitrary stranger, not a vetted operator.

Risk

Likelihood:

• The guard fails on 100% of calls. There is no input, ordering or state that makes it fire, because the value it tests can never become true.

• Exploiting it needs one instruction, no cost beyond the fee, no timing and no cooperation. It is available for the entire lifetime of every fund ever created.

Impact:

• The deadline — the only public commitment a campaign makes about its own lifecycle — carries no guarantee. A contributor who reads fund.deadline before contributing has read a number that can be changed the moment they act on it.

• Live consequence: a creator can set a past timestamp and retroactively close their campaign to new contributions, then reopen it, arbitrarily and repeatedly. contribute (line 29) rejects with DeadlineReached for as long as the past value stands.

• The refund window is equally under creator control: a deadline pushed to u64::MAX means refund (line 69) rejects with DeadlineNotReached indefinitely.

Honest limitation

I set Impact to Low deliberately, and want to be explicit about why rather than let a judge discover it. In this program a separate defect means contribution.amount is only ever assigned 0, so refund moves zero lamports regardless. That makes the refund-blocking consequence above inert today — blocking refund currently blocks a no-op, and no contributor lamports are actually protected by it. The consequence that is genuinely live is the contribution-blocking one, which is a creator griefing their own fundraiser.

So: Likelihood High, because the guard is unconditionally broken; Impact Low, because today's reachable harm is limited. The reason this still matters is that it is a latent hazard sitting directly under the refund mechanism — the moment amounts are recorded correctly, this flag becomes the switch that decides whether contributors can ever exit, and it is currently held by the one party with an interest in it staying off.

Proof of Concept

Three consecutive set_deadline calls, all accepted, with the flag still false afterwards.

Output:

Note on the project's own test suite

tests/rustfund.ts calls setDeadline exactly once and asserts nothing (every check is a console.log), so the suite never exercises a second call and cannot observe that the guard is inert.

Recommended Mitigation

Raise the flag the guard depends on, bound the value, and forbid changing the terms after contributors have committed money.

Taking the deadline as a parameter of fund_create instead would remove the window entirely and make the field immutable by construction — a fund would then never exist in the deadline == 0 state. Note also that the field name is misspelled (dealine_set); renaming it to deadline_set is worth doing in the same change, since the typo is what makes the missing assignment easy to overlook.