L-2: EmergencyBurn still wedges on present-but-undecodable escrowed portfolio (#110B)

[v1ktorrr0x]

Bug

The #131 portfolio_gone escape hatch only fires for data_is_empty() || lamports() == 0 (processor.rs:1017). A wrapper-owned portfolio that is still funded/non-empty but fails decode_portfolio (e.g., a future layout migration flips magic/version/discriminator) takes the else branch → verify_portfolio_program + decode_portfolio → PortfolioDecodeFailed → EmergencyBurn reverts forever.

The NFT, its rent, and the escrowed position are all stranded.

Source Impact

This is the explicitly deferred #110B (README.md:131-135). It's coupled to M-1: a silent layout drift (M-1) is precisely what would make a live portfolio "undecodable."

Risk

• Rent lockup: NFT holder can't reclaim ~0.02 SOL per stranded NFT
• Escrow lockup: position remains escrowed to the NFT program's PDA forever, inaccessible even via direct portfolio operations
• Requires abnormal core state (modified magic/version), so low-severity, but high-impact when it happens

Fix

Add a graceful fallback path in EmergencyBurn: if the portfolio fails decode, skip the eligibility check and just proceed with burning the NFT + closing accounts. The position was already escrowed and can't be modified anyway; the holder just wants their rent back.

Labels: security, deferred

[dcccrypto]

Verified fixed — closing. And fixed with the right narrowness, which is the interesting part.

process_emergency_burn (src/processor.rs:1144-1183) now matches on decode_portfolio and admits only the layout-migration errors, skipping eligibility and proceeding to unwrap:

Err(e @ (PortfolioDecodeError::BadVersion
       | PortfolioDecodeError::BadAccountVersion
       | PortfolioDecodeError::BadLayoutDiscriminator)) => {
    msg!("EmergencyBurn: portfolio present but from an unknown layout version ({:?}) — skipping eligibility, proceeding to unwrap (#110B)", e);
}
Err(e) => return Err(cpi_v16::map_decode_err(e)),

so the wedge you reported — a present-but-undecodable escrow blocking the burn forever — is gone for the case that justifies it.

The reasoning at :1155-1171 is what makes this safe rather than a blanket Ok:

Skipping the gate lets a position be emergency-burned without proving it is flat, and this falls through to UnwrapEscrowedPortfolio, which is not itself leg-gated — so the set of errors that reach it must be exactly the set this fallback was justified by ("a future layout migration changed magic/version"), not every decode failure.

Rejected: TooShort, BadMagic, BadKind, Cast, OwnerMismatch — on a wrapper-owned account these mean corruption or a wrong account, not a migration. OwnerMismatch in particular is a violated engine invariant and must never widen burn eligibility.

The companion portfolio_gone path (:1136) handles the #131 case separately and just as narrowly — 0-byte or zero-lamport only, with any other anomaly deliberately falling through to rejection rather than being read as "gone".