What is the difference between an exit game and in-flight exits in plasma security?

An exit game is the withdrawal incentive structure that uses bonds and dispute proofs to stop dishonest exits. In-flight exits are a separate safeguard that lets users redeem funds even when a malicious operator refuses to include their transaction in a plasma block. Together, they address different failure points in Layer 2 security and user recovery.

Why the Two Mechanisms Solve Different Plasma Failure Modes

An exit game and an in-flight exit are both recovery mechanisms, but they protect against different failure conditions in a Plasma design. The exit game is about contesting dishonest or stale exits so the system can enforce the correct withdrawal order. In-flight exits are about preserving user access when an operator withholds transaction inclusion entirely, which is a different problem from proving the exit itself is invalid.

The distinction matters because plasma security is not just about “can a user leave?”, it is about which part of the exit path can fail. An exit game assumes there is an exit to challenge; an in-flight exit assumes the transaction never made it cleanly into a block and gives the user a fallback path to recover funds.

When you compare them this way, the security boundary becomes clearer: exit games defend the correctness of the withdrawal process, while in-flight exits defend liveness and user recovery under operator censorship or omission.

How Exit Games and In-Flight Exits Fit Together

Exit games usually rely on bonds, challenge windows, and dispute proofs. That structure makes dishonest exits expensive and gives watchers or counterparties time to prove that the exiting state is not valid. In practice, the control is designed to deter fraud by making bad exits contestable before funds are released.

In-flight exits solve a narrower but important gap. If a malicious or unavailable operator refuses to include a user transaction in a Plasma block, the user may still need a way to recover value without depending on the operator’s cooperation. That makes the mechanism a user-protection layer against withholding, not a replacement for dispute-based finality.

Exit games answer: “How do we stop invalid withdrawals from succeeding?”
In-flight exits answer: “How do users recover when the operator will not include their transaction?”
Together, they split security into correctness and recoverability, which is why both are discussed in Plasma designs.

Risk and Threat Considerations

The main risk is assuming one recovery mechanism covers the whole withdrawal problem. If exit games are treated as a general fallback, users remain exposed to operator censorship or withheld inclusion. If in-flight exits are treated as a fraud-proof system, invalid exits can slip through unless there is a separate challenge process.

Failure mechanism: A dishonest operator can either attempt an invalid withdrawal or simply refuse to include a user’s transaction. The first is addressed by dispute-based exit logic, the second by a separate in-flight recovery path.

Impact: Without both controls, users can lose liveness, face delayed recovery, or rely on a withdrawal path that is secure against one failure mode but not the other.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	Plasma exits hinge on controlled authorization to withdraw funds.
	DE.CM — Security Continuous Monitoring	Watching exits and challenges requires ongoing monitoring for invalid or withheld withdrawals.
	RS.RP — Response Planning	Dispute proofs and fallback exits are response mechanisms for withdrawal failures.
Recommendation — Enforce withdrawal authorization and dispute checkpoints before funds are released. Monitor exit activity and challenge events for signs of invalid or censored withdrawals. Predefine response paths for challenged exits and withheld transaction inclusion.
CIS Controls v8	6 — Access Control Management	Withdrawal paths need enforced control over who can move funds and under what conditions.
	8 — Audit Log Management	Exit games depend on evidence that can be reviewed during disputes.
Recommendation — Restrict withdrawal authority to validated, policy-compliant exit conditions. Keep auditable records of exits, challenges, and inclusion decisions.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Withholding or manipulating transaction inclusion is an abuse of exposed transaction-processing interfaces.
Recommendation — Harden exposed transaction interfaces against abuse that blocks or distorts withdrawal flow.

Practitioner Guidance

What to verify: Check whether the design cleanly separates fraud prevention from censorship recovery. If the same mechanism is expected to do both jobs, look for missing challenge windows, weak proof requirements, or an operator dependency that can block redemption.

Decision rule: If you are evaluating a Plasma system, ask which failure is being mitigated first, invalid exit attempts or transaction withholding. That answer tells you whether the security discussion should centre on dispute proofs, user fallback paths, or both.

Practitioner takeaway: The useful mental model is that exit games protect withdrawal correctness, while in-flight exits protect withdrawal availability, and mature Plasma security needs both layers to cover distinct failure points.