From cells to a number

L6 told you cells exist. L13 gave you the per-field math. L16 showed how risk propagates. But we never answered the question that actually produces the flagship output: once you have hundreds of cells for one token, how do they become a single, trustworthy "$X at risk"? Sum them and you get nonsense — WBTC once scored 451% of its own supply. This lesson is the machine that fixes that.

1 · Two numbers live on every cell

Before aggregating, know what you're aggregating. Each Cell (pkg/risk/at_risk_types.go) carries two dollar values, and they answer different questions:

The gap between them is the difference between "this much is at risk in principle" and "this much could be drained in practice." Extractable is the smaller, harder number — it's clamped by where you could actually sell or borrow the stolen value:

// at_risk_extractable.go — per target_role, sum the applicable exit mechanisms,
// SELF-SUBTRACTING the failed venue (you can't drain a contract THROUGH itself).
availableExit := 0.0
for _, mech := range exitMechanismsByRole[role] {
    if role == TargetRoleFocusToken {
        availableExit += mechTotal(mech)              // issuer failure: no self-subtract
    } else if delta := mechTotal(mech) - mechSubtract(mech); delta > 0 {
        availableExit += delta                        // "what's LEFT after draining this venue"
    }
}

2 · The collapse key: value_pool_id

The trick that tames the 451% problem is one string stamped on each cell: value_pool_id (at_risk_value_pool.go, Phase 2.7). Cells that drain the same downstream value pool get the same value_pool_id — even when their target_role and target_id differ. The aWBTC vault cell, the lending-market cell, and the oracle cells all collapse onto one id, because compromising any of them drains the same WBTC.

When no collapse rule applies, it falls back to "<role>:<target_id>" — the pre-2.7 behaviour, i.e. "each target is its own pool."

3 · The aggregation: max-within, sum-across

Here's the heart of it — aggregateEffective (at_risk_aggregate.go). It runs once for at_stake_usd and once for extractable_usd:

func aggregateEffective(cells []*Cell, field cellUSDField) float64 {
    byPool := make(map[string]float64)
    for _, c := range cells {
        if c.Partial { continue }          // 1. DROP partial (multisig signer derivatives)
        pid := c.ValuePoolID
        if pid == "" { pid = role + ":" + tid }  // fallback grouping
        v := field(c)
        if existing, ok := byPool[pid]; !ok || v > existing {
            byPool[pid] = v                  // 2. MAX within each pool
        }
    }
    return floats.KeyedSum(byPool, ...)     // 3. SUM across pools (order-independent)
}

Three moves, and each encodes a real claim about the world:

1. Drop partial cells. Multisig signers each produce a derivative cell sharing the anchor's pool id; keeping them would multiply one threat by its signer count. (More on multisig expansion below.)
2. MAX within a pool. Several cells hit the same dollars — the worst single path is the honest credit. Adding them would double-count the shared value. This is the 451% fix.
3. SUM across pools. Different pools are independent attack classes — losing the Aave position and the Compound position are separate losses, so the rollup is additive.

Worked example — WBTC (illustrative numbers)

Naive cell sum: $4.4B. After value-pool collapse: max-in each pool ($1.0B, $0.4B), then sum-across = $1.4B. Same discipline as L13's max-over-channels and L16's max-over-paths — units that overlap combine by MAX; units that are independent combine by SUM.

4 · The caps: three hard ceilings

Even after collapse, the raw aggregate can exceed reality. applyEffectiveCaps (at_risk_aggregate.go) imposes three final clamps. Order matters.

5 · Where this sits in the whole at_risk run

So you can place the pipeline end-to-end. EnrichAtRisk (at_risk.go) is the entry; it walks each focus token through decomposeCells, then the calculations you just learned:

focus tokens                         // from Redis tokens:{chain} / metadata
   └─> decomposeCells               // the SIX construction paths (next box)
        └─> multisig expansion       // anchor cell + partial signer cells
             └─> computeExtractable  // at_stake → extractable (exit-liquidity bound)
                  └─> stamp value_pool_id
                       └─> applyEffectiveCaps   // drop-partial→max-in→sum-across→caps
                            └─> summarizeCells  // AtRiskSummary stamped on the node
                                 └─> mirror to AT_RISK edges

The output: an AT_RISK edge per cell

The aggregated numbers stamp an AtRiskSummary on the node, but the cells themselves are also mirrored as graph edges (at_risk_edges.go, FORTA-2985): (entity)-[:AT_RISK]->(focus_token), tail = failure point, head = victim token. So a token's own-risk is the sum of its INBOUND AT_RISK edges — exactly the projection you met in L6. The writer also issues an unconditional supersede that deletes any inbound edge not in the current run, keyed on the same $runAt — making the final edge set a pure function of the current cells, replay-safe. (84,802 contract-failure cells vs 7,390 admin cells on a recent run, per the file header.)

What you can now do

• Explain the two dollar values on a cell — at_stake_usd vs extractable_usd — and why extractable is the harder, smaller, exit-liquidity-bounded number.
• Explain value_pool_id as the collapse key that makes overlapping venues count their shared dollars once.
• Recite the aggregation procedure: drop-partial → MAX-within-pool → SUM-across-pools → caps, and justify each step.
• Order the three caps (supply, at-stake invariant, exit) and explain why ordering and the ×1.001 slack matter.
• Connect the whole thing to a token's own-risk = sum of inbound AT_RISK edges, and to the system-wide MAX-for-overlap / SUM-for-independent discipline.