The drainable ceiling

L19 and L20 kept invoking one number as the final ceiling: exit_v2_total. The exit cap in the rollup, the min(at_stake, exit_total) for NAV oracles, the borrow caps — all of them clamp against it. But what is it? It's the answer to a brutally practical question: "if you stole this token, where could you actually turn it into something you keep — and how much?" Stealing $5B of a token nobody will buy is worth $0. Exit-liquidity v2 measures the real cash door.

1 · Four mechanisms, one total

For each focus token T, computeExitLiquidityV2 decomposes the exit into four buckets, each with a total_usd and a by_venue breakdown. The token-level total_usd is their sum:

2 · Counter-token apportionment (the pool/wrap math)

Here's processVenue for a swap venue. For a pool holding T, it sums the USD of every other token in that venue — that's what a seller of T receives:

// at_risk_exit_liquidity.go — processVenue
holds := holdsByVenue[venueID]
var otherTotal float64
for _, h := range holds {
    if _, inWrap := state.wrapClass[h.tokenAddr]; inWrap {
        continue                       // skip T and its wrapped forms — not a real exit
    }
    otherTotal += h.usd                  // counter-token cash you'd receive
}
mech := MechPool
if bridgeVia != "" { mech = MechWrapBridge }   // reached via a derivative → wrap_bridge bucket
state.mechanismTotals[mech] += otherTotal

3 · The bridge pass — and why it's sorted

After the direct pass, computeExitForToken runs a bridge pass: for each permissionless derivative of T, it credits that derivative's venues to the wrap_bridge mechanism (an attacker can wrap T → dump the wrapped form). Two details worth seeing:

• Dedup across passes. seenVenues means a venue counted in the direct pass won't be re-counted in the bridge pass — no double credit.
• Sorted iteration. Derivatives are walked in sort.Strings order. Map order is random and float addition is non-associative, so an unsorted walk would drift by a ulp per run — breaking byte-parity with Python. (The final cross-mechanism sum uses floats.KeyedSum / Neumaier for the same reason — the recurring parity-hygiene discipline you saw in L19's aggregation.)

4 · lending_borrow: where a real bug lived

The lending-borrow bucket is the subtle one, because "how much can you borrow against fresh T?" depends on supply caps and the LTV haircut. computeBorrowValue dispatches on supply_cap_status:

5 · Where it plugs back in

The output is stamped on the focus-token node as exit_liquidity_v2 — {total_usd, by_mechanism, derivative_bridge}. Then it becomes the ceiling everywhere you've already seen:

• L19 exit cap: eff_extractable = min(eff_extractable, exit_v2_total) — the hard per-token upper bound, because all attackers share the one exit pool.
• L20 oracle/drain extractable: the per-mechanism by_venue totals feed computeExtractable, which self-subtracts the failed venue from the applicable mechanisms ("what's left to exit through after draining this contract").
• NAV oracles: min(at_stake, exit_v2_total), or honest-$0 when exit is off-chain only.

What you can now do

• Define exit liquidity as the drainable ceiling — the cash an attacker can turn a stolen position into.
• Name the four mechanisms (pool, wrap_bridge, lending_in_market, lending_borrow) and what each route hands the attacker.
• Explain counter-token apportionment and why T + its wrap class are excluded (you can't exit a token into itself).
• Explain the derivative-as-venue mirage, cross-pass dedup, and the sorted-iteration parity discipline.
• Explain the supply_cap_status dispatch and the LTV-haircut bug ($2.85B Spark false positive) it fixes.
• Trace exit_v2_total into L19's exit cap and L20's self-subtracting extractable.