Rent is permanently locked — `Fund` and `Contribution` accounts are never closed, so the rent-exempt SOL can never be reclaimed
Description
fund_create creates the Fund PDA with init (rent paid by the creator), and contribute creates each Contribution PDA with init_if_needed (rent paid by the contributor). No instruction ever closes either account. withdraw and refund move only the contributed lamports via raw lamport math; they never use Anchor's close = to return the rent-exempt deposit and reclaim the account.
Risk
Likelihood: Low
Applies to every campaign and every contributor account at end-of-life. After a campaign completes (withdraw) or a contributor is refunded, the account's rent-exempt reserve just sits there.
Impact: Low
The rent-exempt SOL paid at account creation (by the creator for the
Fund, by each contributor for theirContribution) is permanently locked and unrecoverable. It is a small per-account amount, but it is real value stranded on-chain for the lifetime of the program, with no code path to retrieve it.
Proof of Concept
Recommended Mitigation
Close accounts when they are no longer needed, returning rent to the payer. For example, close a Contribution on refund and the Fund on final withdrawal:
Lead Judging Commences
[L-04] Unclaimed rent from fund and contribution accounts leads to permanent SOL lockup
## Description neither the `withdraw()` nor `refund()` functions properly close their respective accounts after the funds have been transferred. This results in the rent amount (the SOL required to keep the account allocated on the Solana blockchain) remaining locked in these accounts indefinitely. ## Vulnerability Details In Solana, accounts must maintain a minimum balance to remain "rent-exempt", ensuring they aren't purged from the blockchain. When accounts are no longer needed, best practice is to close them and return this rent to the appropriate party (typically the account creator). The RustFund protocol currently lacks this account cleanup mechanism. - The withdrawal process in `withdraw()` transfers the raised funds from the fund account to the creator - Similarly, the refund process in `refund()` transfers the contribution amount back to the contributor and resets the contribution amount In both functions, the account data is updated, but the accounts themselves remain open, with their rent amount locked. After all funds have been withdrawn or refunded, these accounts serve no further purpose but continue to consume blockchain resources and lock up SOL. ### Proof of Concept 1. Alice creates a fund with a goal of 100 SOL, which requires 0.1 SOL as rent for the fund account. 2. The fund successfully raises 100 SOL from various contributors, each of whom also paid rent for their contribution accounts (approximately 0.05 SOL each). 3. Alice calls `withdraw()` to claim the 100 SOL raised funds, but the fund account itself is not closed. 4. The 0.1 SOL rent for the fund account remains locked in the account indefinitely. 5. Similarly, when contributors request refunds through the `refund()` function, their contribution accounts are updated but not closed. 6. The rent for all contribution accounts (e.g., 10 contributors × 0.05 SOL = 0.5 SOL) remains locked indefinitely. 7. Over time, as more funds are created and more contributions are made, the amount of permanently locked SOL grows. ## Impact - Economic Inefficiency, - Blockchain bloat, - Reduced user returns ## Recommendations Implement proper account closure in both the `withdraw()` and `refund()` functions.
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Judging
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsRewards Distribution
The contest is complete and the rewards are being distributed.