<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Systemic Risk Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/systemic-risk/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/systemic-risk/</link>
	<description>Crypto fees, wallets and offers — checked against the terms page</description>
	<lastBuildDate>Tue, 27 Oct 2026 08:02:06 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>

<image>
	<url>https://www.ladyww.net/wp-content/uploads/2026/10/mark-512-150x150.png</url>
	<title>Systemic Risk Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/systemic-risk/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Composability Risk: When One Protocol Breaks Five</title>
		<link>https://www.ladyww.net/composability-risk/</link>
					<comments>https://www.ladyww.net/composability-risk/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 08:02:06 +0000</pubDate>
				<category><![CDATA[DeFi]]></category>
		<category><![CDATA[Composability Risk]]></category>
		<category><![CDATA[Defi Composability]]></category>
		<category><![CDATA[DeFi Risk]]></category>
		<category><![CDATA[Liquidation Cascades]]></category>
		<category><![CDATA[Liquidity Risk]]></category>
		<category><![CDATA[Protocol Dependencies]]></category>
		<category><![CDATA[Smart Contract Risk]]></category>
		<category><![CDATA[Stacked Positions]]></category>
		<category><![CDATA[Systemic Risk]]></category>
		<category><![CDATA[Wrapper Tokens]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/composability-risk/</guid>

					<description><![CDATA[<p>Composability risk is the risk that a position built from several protocols fails because of its weakest layer rather than its average. Each layer is a claim on the one [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/composability-risk/">Composability Risk: When One Protocol Breaks Five</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Composability risk is the risk that a position built from several protocols fails because of its weakest layer rather than its average. Each layer is a claim on the one beneath it, so a pause, a bad parameter or a broken price at the bottom freezes everything stacked on top. Composability risk is not the sum of the individual risks; it is their correlation.</p>
<p>The diagram always looks tidy: an asset becomes a receipt token, the receipt is supplied as collateral, the borrowed asset is deposited again. Four boxes, four audits, four dashboards. The exposure underneath is one asset and one price path, viewed four times.</p>
<ul>
<li><strong>Layers share more than they look.</strong> A stack assembled from different teams usually rests on the same base asset, the same oracle and the same block space.</li>
<li><strong>Failure propagates upward.</strong> A pause at the base layer stops withdrawals at every layer above it, regardless of how healthy those layers are.</li>
<li><strong>Correlation dominates the maths.</strong> Three independent 5% failure chances compound; three correlated ones behave like the single worst layer.</li>
<li><strong>Depth is invisible on a dashboard.</strong> Most interfaces show the top-level position and hide the contracts it depends on.</li>
</ul>
<h2>What composability risk looks like in a position</h2>
<p>It looks like a single balance that depends on four contracts, three of which you have never opened.</p>
<h3>The stack</h3>
<p>A typical stack starts with a base asset held in a wrapper that issues a receipt. The receipt is supplied to a lending market as collateral, and the borrowed asset is deposited into a strategy that reports a single yield figure. Each step is individually reasonable and each step adds a dependency.</p>
<p>The dependencies are not equal. The base asset&#8217;s price affects every layer, the wrapper&#8217;s redemption affects the receipt&#8217;s price, the lending market&#8217;s parameters decide whether the position can be liquidated, and the strategy&#8217;s code decides whether the reported balance is real.</p>
<h3>Where the layers touch</h3>
<p>Layers touch at three seams: the exchange rate between a receipt and its underlying, the oracle pricing that receipt, and the liquidity available to exit. Each seam is where one protocol&#8217;s assumption becomes another&#8217;s input.</p>
<p>The seams are where failures travel. A wrapper that pauses redemptions does not need to lose a single unit of the underlying to break a position three layers up. It only needs to stop converting, so the receipt trades at a discount and the market that prices it at par liquidates borrowers who did nothing wrong.</p>
<blockquote><p>A stack of four protocols does not give you four risk budgets. It gives you one asset, four exit doors and a queue at each of them.</p></blockquote>
<h2>Three ways a stack shares one failure</h2>
<p>The shared failure is usually a single input that several layers read at once.</p>
<h3>Wrapped assets</h3>
<p>A receipt token concentrates the wrapper&#8217;s risk into the token itself. If redemption slows, the token trades below its underlying, and every market that accepts it as collateral inherits the discount. Positions far from the wrapper — holders who never interacted with it directly — can be liquidated because their collateral was priced at par while the market priced it lower.</p>
<h3>Shared collateral</h3>
<p>Recursive positions reuse the same collateral multiple times. Supply, borrow, re-supply, borrow again. Each loop adds a claim on the same base asset, and the reported total exposure across the stack exceeds the capital actually present. When the base asset moves, every loop moves together and the unwind is a single crowded exit rather than several independent ones.</p>
<h3>Shared oracles and shared liquidity</h3>
<p>Two protocols that price an asset from the same feed share a failure mode completely. Two protocols that rely on the same pool for exit liquidity share a queue. Diversity of code does not create diversity of inputs, and it is the inputs that fail together.</p>
<h2>Why composability risk arrives all at once</h2>
<p>Composability turns separate incidents into one event because the layers are evaluated in the same block and by the same participants.</p>
<p>Liquidation bots watch the same signals. When one market becomes liquidatable, the selling arrives at the venue every other layer prices from and pushes the next market toward its threshold. The sequence can complete before a person opens a dashboard, and it is a sequence precisely because the layers are connected.</p>
<p>Atomicity cuts both ways. Within a single transaction, a failure reverts the whole call and nothing is lost — that is genuine protection. Across transactions, a position that spans four protocols cannot be unwound in one step, so an exit takes as many steps as the stack has layers, at whatever prices exist when each step executes.</p>
<p>Suppose three layers each carry a 5% chance of failing in a year. If those failures were independent, survival would be 0.95 cubed, about 86%. They are not independent. A single depeg, feed error or pause reaches all three, so the realistic survival rate sits closer to the weakest layer&#8217;s — and the weakest layer is usually the one with the least liquidity.</p>
<h2>Mapping a stack before you deposit</h2>
<p>Map the position from the asset up, and stop when you reach something you cannot describe in one sentence.</p>
<ol>
<li>Start with the base asset. Name it, and note whether anything above it can change its redemption terms.</li>
<li>List the wrapper or receipt token, and check whether redemption is instant, queued or pausable.</li>
<li>Note the oracle that prices each token in the stack, and whether two layers read the same feed.</li>
<li>Identify the market where the position can be liquidated, and its threshold and penalty.</li>
<li>Find the strategy or aggregator on top, and read what it does with the deposited asset rather than what it reports as yield.</li>
<li>Check whether any layer can pause transfers, and who holds that authority.</li>
<li>Write the exit path in order. If it requires three transactions across three protocols, the position needs three times the buffer you would otherwise hold.</li>
</ol>
<p>Two questions do most of the work: which single event would hurt every layer at once, and how many transactions does it take to leave.</p>
<h2>Single protocol against a stack</h2>
<p>The comparison is not about which is safer in general, but about which risks you are paid for and which you absorb without noticing.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Layer</th>
<th>What it adds</th>
<th>What breaks there</th>
<th>Who absorbs it</th>
</tr>
</thead>
<tbody>
<tr>
<td>Base asset</td>
<td>Price exposure</td>
<td>Depeg, chain congestion</td>
<td>Every layer above</td>
</tr>
<tr>
<td>Wrapper</td>
<td>Redemption claim</td>
<td>Paused or queued exits</td>
<td>Receipt holders and their lenders</td>
</tr>
<tr>
<td>Lending market</td>
<td>Leverage</td>
<td>Parameter change, oracle error</td>
<td>Borrowers and depositors</td>
</tr>
<tr>
<td>Strategy</td>
<td>Reported yield</td>
<td>Contract logic, reporting lag</td>
<td>Depositors in the strategy</td>
</tr>
<tr>
<td>Bridge</td>
<td>Access to another chain</td>
<td>Validator set, message delay</td>
<td>Everyone holding the bridged claim</td>
</tr>
</tbody>
</table></div>
<p>A stack is worth it when the extra layer buys something you need — cheaper borrowing, a redemption you will use. It is not worth it when the layer exists only to add a yield figure to a position that already had the exposure.</p>
<p>The post <a href="https://www.ladyww.net/composability-risk/">Composability Risk: When One Protocol Breaks Five</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/composability-risk/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
