SKN3X.COM

Building a dependency map

A four-step procedure whose most important output is the list of what could not be established.

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 build a dependency-based listing for a portfolio.
  • You can report the limit of your own survey as a row of its own.

Check your prior knowledge

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

Core concept

Fact

Four levels, always the same

Chain, bridge, stablecoin, oracle. These four recur across every segment and are the levels at which a single failure hits several positions at once. A map surveying them covers most of the dependency exposure — not all of it, but the part that recurs systematically.

Interpretation

Two levels deep is almost always enough

The first level is the protocol the capital sits in; the second is the components it uses itself. Going deeper yields rapidly diminishing returns, because the third level usually contains the same four categories again. Completeness at the second level across all positions matters more than depth.

Uncertainty

The “not established” row is the result

A map without that row claims a completeness no survey can deliver. With it, it becomes a defensible statement: “these four dependencies are surveyed; for two positions the oracle attribution could not be established”. That is less satisfying and considerably more usable — because a reader knows where to ask.

Definitions

Dependency map
A listing of positions by shared components rather than by protocol.
Second level
The components the protocol held uses itself.

Model

  1. List positions, with value

  2. Per position, survey the four levels: chain, bridge, stablecoin, oracle

  3. Sum by dependency rather than by protocol

  4. Not established as its own row, with value and position count

The procedure in four steps — Step 4 turns the map from an assertion into a statement with a range.

Formulas

Concentration per level

Share = Σ position value with this dependency / portfolio value
dependency
a specific chain, bridge, stablecoin or oracle provider

Limit: Positions with unestablished attribution are missing from the numerator and appear to lower the share. They therefore need to be reported separately, not silently treated as “without this dependency”.

Worked example

A map with an honest gap

Positions
8, USD 12m in total
Stablecoin X
5 positions, USD 7.4m (62 %)
Oracle provider Y
4 positions, USD 5.1m (43 %)
Not established
2 positions, USD 1.8m (15 %)

The oracle share is at least 43 % and at most 58 %, depending on how the two unestablished positions would be attributed.

A range instead of a number — and the range is the real information.

Reading: Without that row it would read “43 %”, and nobody would know the value can reach 58 %. The range also says how much work closing it would take: two positions.

Retrieval

Why does “not established” belong in the map as its own row?
How deep should a dependency map go?

Exercise on real data

Pick three markets and survey the four levels for each, as far as the data allows. Explicitly record what you could not establish.

Survey three markets' dependency chains →

Compare your map with the case study: how many independent risks remain there after the same survey?

Case study as a cross-check →

Application

Your map gives a 62 % stablecoin share with 15 % of positions unestablished. How do you report it?

Related case studies

Institutional reading

Bank
Is the dependency map refreshed at the same frequency as the position listing?
Insurance
Does the map also cover the dependencies of risks written, not only of its own investments?
Asset management
Does any surveyed level sit above the internal concentration limit?

Metrics in this lesson

Key takeaways

Evidence