Aggregation and risk transfer

Why spreading across protocols is not spreading across dependencies — and what a risk transfer is worth when it shares the same trigger.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

You can compute the aggregate behind a shared trigger rather than merely counting positions.
You can check whether a risk transfer carries the same trigger as the risk being transferred.
You can state a claims trigger so it is decidable before the event.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

What distinguishes a single risk from an accumulation risk in your organization?
What is a loss measured against in your organization — the event or the cause?
Who bears the risk when the risk carrier itself fails?

Core concept

Fact

Accumulation forms at the shared dependency

An accumulation risk exists when many individually small positions lose at the same time on the same trigger. In DeFi that shared trigger is rarely a shared market and usually a shared dependency: the same price oracle, the same bridge, the same stablecoin as the quote asset, the same layer-2 sequencing. The positions look independent because they sit on different protocols — what they share is what sits underneath them.

Interpretation

Spreading across names is not spreading across causes

Five positions across four protocols look diversified. If four of them depend on the same oracle, the aggregate behind that trigger is 80 percent of the capital — the spreading has distributed names, not causes. This is only checkable if dependencies are recorded per position; the list of protocols alone does not reveal it.

Risk

A risk carrier sharing the trigger carries little

When protocol risk is transferred to another on-chain mechanism, what that mechanism itself depends on has to be examined. If the cover hangs on the same oracles, bridges or stablecoins as the covered position, the loss event and the carrier's ability to pay tend to coincide. The transfer then changes the shape of the risk, not its size.

Uncertainty

“Hack” is not a trigger

A trigger must be decidable before the event without anyone knowing the actor's intent. “Unauthorized access” and “exploitation of a vulnerability” can be disputed afterwards; an outcome following from an intended parameter often looks on-chain like an attack. What is decidable are observable conditions: an outflow above X percent of deposited funds within Y blocks, evidenced by named sources.

Definitions

Accumulation risk: The risk that many separately underwritten risks materialize together through one common event.
Claims trigger: The condition agreed in advance whose occurrence gives rise to an obligation to pay.
Shared dependency: A component that several apparently independent positions all rely on at once.

Model

List positions per protocol
Record the components per position: oracle, bridge, stablecoin, sequencing
Sum the amounts per component
Examine the largest amount — not the most frequent component
Only then adjust cover or allocation

From protocol name to cause — A component appearing in many small positions can matter less than one in two large ones.

Formulas

Aggregate per trigger

aggregate(t) = sum of the position_amounts whose dependency_list contains t

t: The shared trigger under examination, for instance one particular oracle
position_amount: The amount deployed in the individual position
dependency_list: The components recorded per position that it relies on

Limit: The sum measures the nominal exposed, not the loss. How much is actually lost when t occurs depends on the position and is therefore a separate assumption — the formula does not supply it.

Worked example

Four protocols, one trigger

Positions: 20 percent of capital each across five pools, four protocols
Dependency A: oracle O in four of the five pools
Dependency B: bridge B in two pools
Assumed loss given O: 40 percent, explicitly an estimate

Aggregate(O) = 4 × 20% = 80% of capital. Expected loss on occurrence = 80% × 40% = 32% of capital. Aggregate(B) = 2 × 20% = 40%.

The allocation carried as diversified has an 80 percent concentration behind trigger O.

Reading: The 40 percent loss ratio is an assumption, not a measurement — it belongs in the paper as one. The 80 percent, by contrast, is readable as soon as dependencies are recorded. So the action concerns the recording first and the allocation second.

Retrieval

Diversified, because six different protocols are involved.Concentrated: for that trigger what counts is the sum of the five positions, not the number of names.Not assessable while the loss ratio is unknown.

Because such events are too rare.Because it presupposes the actor's intent and so becomes disputable after the event; what is decidable are observable conditions.Because on-chain data allows no conclusions about outflows.

Exercise on real data

Use the guiding questions as a recording sheet and note, for three explorer pools, which components they share.

Dimension 10: dependencies →

In the constructed scenario, determine the trigger with the largest aggregate.

Case study: dependency chain →

Application

You are to build an accumulation overview for a portfolio of eight positions. Describe the procedure and the limit of the result.

Related case studies

Institutional reading

Insurance: Which shared dependency would create the largest aggregate in your book?
Bank: Which of these triggers appear in the operational risk register today?
Asset management: Which reported figure would make a concentration across protocol boundaries visible?

Metrics in this lesson

TVL (Total Value Locked)

Key takeaways

The aggregate belongs to the trigger, not to the protocol name.
A risk carrier using the same components tends to fail at the same time as the loss occurs.
A trigger must be decidable without knowing anyone's intent.

Evidence

EVD-2026-0004
Annual Review of Financial Economics — Smart Contracts and Decentralized Finance