MAX here, SUM there, MIN once — the single principle underneath every risk combinator. ~13 min.
Synthesizes: L13 · L16 · L19 · L38Anchor: double-counting an attackNew: predict the combinator
Across the risk lessons you kept meeting a choice: combine these numbers with MAX… no, with SUM…
wait, here it's MIN. It can feel like a grab-bag of conventions. It isn't. There's one principle, and once you
see it you can predict the right combinator for any new metric — and spot a wrong one in code review. This lesson
connects what you already know into that single idea.
Your anchor: how to double-count an attack
Say a wallet can drain a token three ways — hold it directly, control its admin, manipulate its oracle — and each route
reaches the same $1B of TVL. What's "at risk"? Not $3B. It's $1B — the same dollars, reachable three ways. Add them
and you've invented $2B that doesn't exist. That mistake, at scale, is how a metric reports 451% of a token's supply
or a single position over $1 trillion. Avoiding it is what the whole combinator family is for.
1 · The principle, in two questions
To combine a set of values, ask two things:
1. Do they overlap?
Overlapping (drain the same underlying value) → COLLAPSE to one representative. Adding would double-count.
Independent (separate value) → COMBINE them. Adding is correct.
2. Which way does the question point?
Worst-case ("how exposed / attackable?") → take the MAX (or, for collapse, the worst single path).
Best-case ("how protected / well-governed?") → take the MIN.
Two axes, and the combinator falls out:
Overlapping → collapse
Independent → combine
Worst-case, dollars
MAX (worst single path, once)
SUM
Best-case, dollars/ratio
MIN (best single guardian)
—
Independent probabilities
—
noisy-OR1−∏(1−pᵢ)
2 · The family — every member you've met
Where
Combining…
Op
Why
admin_risk_usd (L13)
6 attack channels on one token
MAX
channels overlap (same TVL reachable many ways); worst path; summing → the >$1T bug
exposure-BFS (L16)
all paths to a node
MAX
paths overlap on the same exposure; strongest single path is the honest measure
at_risk rollup (L19)
cells in one value_pool
MAX
same dollars reached differently → credit once (the 451%-of-supply fix)
at_risk rollup (L19)
across different value pools
SUM
independent attack classes → genuinely additive
exit-liquidity v2 (L21)
4 exit mechanisms
SUM
pool / wrap / lend-in / lend-borrow are independent cash-out routes
cost allocation (L35)
4 load signals
SUM (weighted)
HOLDS / PROTO / compute / alerts are independent cost drivers
governance_risk (L38)
a node's admins
MIN
best-case question — a node is as well-governed as its best-structured controller
node_risk_score (L13/L38)
gov / longevity / audit / firewall
noisy-OR
independent probabilities compound: 1 − ∏(1−pᵢ)
The "aha"
These were never eight separate decisions. They're one principle — collapse what overlaps, combine what's
independent; take the worst for danger, the best for protection — applied eight times. The unit then picks the
combine operator: dollars add, probabilities noisy-OR. That's the whole family.
3 · The direction flip — MAX vs MIN on the same nodes
The subtlest member is governance_risk, because it inverts the direction. Compare it to admin_risk — both look
at a node's admins, and they go opposite ways:
admin_risk_usd (L13)
governance_risk (L38)
Question
"how much can an attacker take?"
"how well-governed is this node?"
So you want
the worst (easiest) path → MAX
the best controller → MIN
Because
an attacker picks the weakest channel
a node is as safe as its strongest guardian
The question sets the direction
Same inputs, opposite operator — and neither is a mistake. Danger metrics are worst-case (max); quality metrics are
best-case (min). When you read a new metric, the operator tells you what question it's secretly asking. (And yes — that
governance MIN is debatable, since an attacker targets the weakest admin; it's a deliberate, parity-locked modelling
choice, L38. Recognizing the direction is what lets you even have that debate.)
4 · Why MAX, not SUM, for overlap — and the nets that catch a slip
The anti-double-count is the heart of it. Summing overlapping attack values doesn't just over-report a little — it
produces physically impossible numbers, because the same dollars get counted once per route. The system treats those
impossibilities as tripwires:
Tripwire
Catches
> $1T = bug (CLAUDE.md)
a position bigger than any real one ⇒ a double-count leaked somewhere
supply cap (L19)
effective at-stake > token supply ⇒ counted the same supply twice
conservation (L32)
Σ HOLDS > totalSupply×1.02 ⇒ overcounted holdings
HHI ≤ 1 (L39)
concentration > 1 ⇒ shares that don't sum to 1 (a dedup miss)
A double-count has a smell
Every one of those nets is the same reflex: a risk number that exceeds what's physically possible means you added
things that overlap. When you write or review a new metric and the output blows past supply, past $1T, past 1.0 — don't
reach for a clamp first. Ask what you summed that should have been collapsed.
The superpower this gives you
Faced with a new field — "risk across a customer's whole portfolio," say — you no longer guess. You ask: do the
portfolio's tokens overlap in value? (some do — shared markets → collapse those) Is it a danger or a quality question?
(danger → max/worst) What's the unit? (dollars → sum the independent parts). The combinator is derivable, not
memorized — and a PR that sums overlapping exposure now jumps out at you in review.
Predict the combinator
1. A wallet can drain a token via direct holdings, admin control, and oracle manipulation — all reaching the same $1B. How should the three be combined into "at risk"?
2. Why is exit-liquidity v2 a SUM over its four mechanisms while at_risk is a MAX within a value pool?
3. admin_risk takes the MAX over a node's admins-as-attack-channels, but governance_risk takes the MIN over the same node's admins. What flips the direction?
4. node_risk_score combines governance / longevity / audit / firewall with a noisy-OR, not a sum or a max. Why noisy-OR?
5. A new metric reports a token's at-risk value as 230% of its total supply. What's the most likely cause?
6. The > $1T = bug rule, the supply cap, the conservation check, and HHI ≤ 1 are all instances of what single idea?
7. You're adding "total risk across a customer's portfolio." Two of their tokens are both supplied to the same Aave market. How do you combine?
8. A reviewer sees a PR that sums two exposure paths into a node's risk and the result exceeds the node's USD value. The right instinct is…
↳ Ask your teacher
Try: "Is noisy-OR really 'anti-double-count', or a different family?" ·
"Where would a SUM-of-overlapping bug most plausibly sneak into a new feature?" ·
"How does max-over-paths stay exact in the BFS (the single-visit argument)?" ·
"Is the governance MIN ever wrong in practice — a real weak-admin miss?" ·
"What unit would force yet another combinator we haven't seen?"
What you can now do
State the principle: collapse what overlaps (max/min), combine what's independent (sum/noisy-OR).
Use the two questions — overlap? worst-or-best? unit? — to derive the right combinator for a new metric.
Explain the MAX-vs-MIN direction flip (danger vs quality) on the same admin set.
Place every combinator in the codebase (admin_risk, exposure, at_risk rollup, exit liquidity, cost, governance, node_risk_score) in the family.
Read a physically-impossible risk number as a double-count tripwire, and find the wrong SUM rather than clamp it.
A synthesis, not a new mechanism
Nothing here was new code — it was a lens. The risk engine's seemingly-scattered MAX/SUM/MIN/noisy-OR choices are one
coherent discipline, and you can now both predict and audit them. That's the kind of understanding that turns "I've read
the code" into "I could change it without breaking the invariant."