Worked example · 2022-08

OptiFi accidental program closure — Solana — 2022-08-29

Loss: approximately $661k locked, not stolen — the entire usable balance of OptiFi, a Solana-based options DEX, was rendered unrecoverable when a developer accidentally invoked Solana's closeAccount on the protocol's main program account, irreversibly bricking the deployed program. The funds were not extracted by an attacker; they remain on-chain at addresses that no longer have a working program to interact with them, effectively unrecoverable absent direct ledger intervention by the Solana validator set (which was not requested or granted).
Recovery: none. The accidental closure was irreversible at the protocol layer. Solana's closeAccount instruction on a program account is a one-way operation; the program-data account's lamports are reclaimed, and the program is no longer executable. The Solana ecosystem at the time provided no mechanism — and as of the OAK v0.1 cut still provides no mechanism short of validator-set-coordinated state intervention — to undo this kind of accidental closure. OptiFi disclosed the incident publicly the same day, walked through the operational sequence that produced it, and effectively wound down the protocol. Approximately $661k of TVL was permanently locked.
OAK Techniques observed: OAK-T9.004 (Smart-Contract Logic Flaw — operator-side access-control / human-error sub-class) — primary. The classification under T9.004 is deliberate and is the load-bearing teaching point of this case: T9.004 covers operator-side access-control mistakes equivalently to attacker-driven exploitation. The same access-control surface that, if mis-designed, allows an attacker to call a privileged instruction also, if used carelessly by the operator, allows the operator to do something irreversible and catastrophic. The OptiFi case is the cleanest worked example of the operator-side branch of this surface in the Solana ecosystem.
Attribution: unattributed — self-disclosed operator-side error, no attacker. The OptiFi team publicly identified the specific developer action (an accidentally-piped solana program close command run against the deployed program rather than against an intended buffer or scratch account) and the absence of an upgrade-authority guardrail that would have made the command a no-op or required an additional confirmation step. This is not an attacker-attribution case in the conventional OAK sense; the "actor" is the operator team itself, and the disclosure is voluntary and detailed.
Key teaching point: defenders should treat operator-side access-control mistakes equivalently to attacker-driven access-control exploitation. The same upgrade-authority key that, in the hands of an attacker, would be a closeAccount-driven catastrophe surface is, in the hands of a careless or hurried operator, the same catastrophe surface with no attacker required. T9.004 mitigations that treat "the operator is trusted" as a binary distinction miss the operator-side branch entirely. The OptiFi case is OAK's anchor for the framing that operator-side access-control hygiene (multi-signature on irreversible operations, mandatory confirmation steps, separate keys for separate destructive operations) is a mitigation surface inside T9.004 rather than outside it. The Solana-side closeAccount semantics — irreversible at the protocol layer, recoverable only via validator-set discretionary intervention — make this surface particularly unforgiving on Solana relative to EVM-side analogues (where program code is immutable post-deploy and there is no equivalent single-instruction "delete the program" operation).

Summary

OptiFi was a Solana-based options DEX in early production deployment in mid-2022. On 2022-08-29, during a routine deployment / upgrade workflow, a developer on the OptiFi team executed a solana program close command intended to clean up a buffer account but, due to an environment / argument error, ran the command against the deployed OptiFi main program account itself. The command succeeded. The program account was closed, the program-data account's lamports were reclaimed, and the OptiFi program was no longer executable.

Because the program was no longer executable, the on-chain state accounts owned by the OptiFi program — including all user-deposit accounts, position accounts, and TVL-bearing accounts — became inaccessible. The lamports and tokens stored in those accounts continued to exist on-chain, but no instruction could read or modify them: the only program authorised to interact with them was no longer deployed, and Solana's account-ownership model does not admit transfer of ownership to a different program after the fact without the original program's cooperation.

OptiFi disclosed the incident publicly the same day. The post-incident communication identified:

The specific command sequence that produced the closure (an operator running solana program close with the wrong program-id argument).
The absence of an upgrade-authority guardrail that would have prevented the command from succeeding without an additional confirmation or multisig step.
The irreversibility of the operation at the protocol layer.
The estimated locked TVL (~$661k).

The team did not request — and the Solana validator set did not provide — a coordinated state-restoration intervention. The protocol effectively wound down. The locked funds remain on-chain at the closed program's owned accounts.

For OAK's purposes OptiFi is the canonical operator-side T9.004 worked example. It demonstrates that the access-control surface that defenders model for attacker-driven exploitation is the same surface that bites on operator-side human error, and that the Solana-side closeAccount semantics make the operator-side branch of this surface particularly unforgiving. The total absence of any attacker — and the team's detailed self-disclosure — make the case structurally clean in a way that attacker-driven cases are not.

Timeline (UTC)

When	Event	OAK ref
Pre-event	OptiFi deploys options-DEX program on Solana with upgrade-authority controlled by a single deploy key; no multisig guardrail on `program close`-class operations	T9.004 surface (latent — operator-side access control)
Pre-event	OptiFi developer team performs routine deployment / upgrade operations in a CLI environment that conflates buffer-account program-ids with deployed-program program-ids	(operational substrate)
2022-08-29	Developer runs `solana program close` intending to target a buffer account; command argument resolves to the deployed OptiFi main program account; closure succeeds	T9.004 operator-side execution
2022-08-29	OptiFi user-deposit / position / TVL accounts become inaccessible (no executable program to interact with them); ~$661k of TVL effectively locked	funds-locked outcome
2022-08-29	OptiFi team publicly discloses the incident; walks through the command sequence and the missing guardrail	(transparency / self-disclosure)
Days following	OptiFi team confirms no protocol-layer recovery is possible; does not pursue validator-set-coordinated intervention	(recovery state)
Continuing	Locked funds remain on-chain at the closed-program accounts; protocol effectively wound down	(final state)

What defenders observed

The technical surface is the same as an attacker-driven catastrophe. A hostile actor with control of OptiFi's upgrade-authority key could have produced an identical outcome — the program closed, the funds locked, the protocol bricked. The defender's mitigation surface is therefore the same: control of the upgrade-authority key, multisig on irreversible operations, mandatory confirmation on program close-class commands, separate keys for routine vs destructive operations. The fact that the actual cause was a CLI typo rather than a key compromise does not change the mitigation; the mitigation prevents both. Defenders writing T9.004 mitigations should not split the operator-side and attacker-side surfaces into separate frameworks; they are the same frame.
Solana's closeAccount semantics are unforgiving. EVM-side smart-contract code is immutable after deployment; there is no analogue of closeAccount that bricks a deployed program. EVM-side equivalent failure modes exist (the Parity multisig 2017 self-destruct case is the closest analogue, where a selfdestruct call on a library contract bricked downstream multisigs), but they are rare and structurally specific. Solana's program-deployment model — where a program is an account and that account can be closed — places closeAccount (or its CLI wrapper, solana program close) in the routine operator toolset. The operator-side error surface is therefore both larger (more programs are routinely closed in normal workflows for buffer / upgrade-staging cleanup) and more catastrophic (a single wrong argument can be terminal). Defenders evaluating Solana-side operator hygiene must treat this as a first-class consideration rather than as an EVM-style edge case.
Voluntary, detailed self-disclosure is itself a defender observable. OptiFi's post-incident communication identified the specific command sequence, the missing guardrail, and the irreversibility. This is materially more useful for downstream defender learning than the modal attacker-driven case (where the operator's pre-event posture is reconstructed from on-chain artefacts and partial cooperation). Worked examples in the operator-side branch of T9.004 should expect detailed self-disclosure — the operator has no incentive to obscure the cause, because there is no attacker to negotiate with — and contributors should preserve the disclosure record in detail.
No recovery is the realistic outcome for closeAccount-driven operator-side cases. Solana's validator-set-coordinated state intervention (the recovery primitive demonstrated in the Cetus 2025 case at $162M scale) was not invoked for OptiFi. The implicit threshold for invoking that primitive — large absolute loss, clear-cut exploit, broad social legitimacy of the action, reachable validator coalition — was not met by OptiFi's case (small absolute loss, no exploit, the action would be restoring an operator's mistake rather than freezing an attacker). Defenders writing recovery-framework documentation should preserve the asymmetry: the validator-set-coordinated primitive on Solana / Sui / Aptos is realistically available for clear-cut large-scale exploits where the social legitimacy of the action is unambiguous; it is not realistically available for operator-side mistakes at modest scale, even when the operator self-discloses fully.
$661k locked is small in absolute terms; the structural lesson is large. OptiFi's loss is below the threshold for many incident-tracker reports. Its inclusion in OAK is justified by the structural distinctness of the case (the only operator-side T9.004 case at non-trivial scale in the v0.1 corpus) and by the framing it enables (T9.004 covers operator-side mistakes equivalently to attacker-driven exploitation). Defenders writing case-selection criteria should preserve the framing-distinctness justification as independent of absolute loss magnitude.

What this example tells contributors writing future Technique pages

T9.004 explicitly covers operator-side access-control / human-error mistakes. This is the central T9.004 framing decision OAK needs to make explicit. The same access-control surface that defenders model for attacker-driven exploitation is the same surface that bites on operator-side human error. T9.004 pages should make this framing explicit, and contributors writing T9.004 worked examples should expect both branches (attacker-driven and operator-side) to be in scope. The OptiFi case is the canonical operator-side anchor for the framing.
Solana-specific operator-side surfaces deserve a sub-page. program close, upgrade-authority key management, multisig configuration on Solana programs, the Squads multisig vs single-key deploy distinction, and the operational hygiene around buffer-account vs program-account distinctions are all Solana-specific operator-side concerns that do not generalise cleanly to EVM-side mitigation patterns. T9.004 mitigations on Solana should anchor on this Solana-specific surface; the OptiFi case is the v0.1 anchor.
Self-disclosed operator-error cases are a real worked-example sub-class. OptiFi is the cleanest example, but the broader sub-class includes accidental-burn cases (multiple historical examples on EVM and Solana), accidental-multisig-misconfiguration cases (the Parity 2017 case is the canonical EVM-side instance), and accidental-permission-revocation cases. Worked examples in this sub-class share the structural property of voluntary detailed self-disclosure and the absence of an attacker; they fail T9.004 not because of an attacker's actions but because of the operator's. Contributors writing this sub-class should preserve the framing.
No-attacker is itself an attribution status. OptiFi has no attacker. The "Attribution" header should reflect this — self-disclosed, no attacker — rather than collapsing it into a pseudonymous or unknown framing that misleadingly implies an adversarial actor. Worked-example metadata schemas should accommodate the no-attacker case as a first-class attribution status.

Public references

[optifipostmortem2022] — OptiFi official post-incident communication describing the solana program close operator-error sequence and the locked-TVL outcome.
[rektoptifi2022] — Rekt News forensic write-up of the OptiFi accidental closure, including the operator-error framing.
[solanadocsprogramclose2022] — Solana documentation on the solana program close instruction and its irreversibility semantics.
[ottersecsolana2022optifi] — OtterSec / Solana-ecosystem analyst commentary on the operator-side hygiene lessons.
See also /examples/2017-07-parity-multisig.md for the closest EVM-side analogue (accidental selfdestruct on a library contract bricking downstream multisigs, attributed to a non-malicious researcher exercising an unintended privileged surface).

Discussion

OptiFi is OAK's canonical operator-side T9.004 worked example, and the framing decision the case forces is the load-bearing artefact: T9.004 covers operator-side access-control mistakes equivalently to attacker-driven exploitation, because the access-control surface is the same in both directions. A T9.004 framework that splits the two branches into separate tactic / technique IDs would mis-model the mitigation surface — multisig on the upgrade-authority key, mandatory confirmation on irreversible operations, separate keys for separate destructive operations are all the same mitigations, applied to the same surface, regardless of whether the actor invoking the surface is hostile or careless. OptiFi makes the case for the unified framing explicit by being the cleanest operator-side instance.

The Solana-side closeAccount semantics are the secondary teaching point. Solana's program-deployment model places the catastrophe surface in the routine operator toolset in a way that EVM does not. Defenders modelling Solana-side operator hygiene must treat solana program close, upgrade-authority management, and multisig configuration as first-class concerns rather than as edge cases imported from EVM-side frameworks. The OptiFi case is the v0.1 anchor for this framing.

The total absence of an attacker, combined with the team's detailed self-disclosure, makes OptiFi an unusually clean case to write up — the operator has no incentive to obscure the cause, the on-chain artefacts are unambiguous, and the missing-guardrail framing is exactly the framing the team itself adopted. Contributors writing other operator-side T9.004 worked examples should expect this transparency level and preserve the disclosure record in detail; it is the rare case where the worked-example layer has fewer epistemic gaps than the typical attacker-driven incident.

For OAK's broader credibility, including OptiFi in v0.1 closes a framing gap: it establishes that the framework treats operator-side mistakes as first-class T9.004 instances rather than as out-of-scope operational hazards. This is a defender-facing framework decision with consequences for how T9.004 mitigations are written across the corpus, and the OptiFi case is the cleanest empirical anchor for the decision.

Techniques demonstrated (1)

OAK-T9.004 Access-Control Misconfiguration