Make the Waterfall Immutable Or Don’t Bother
The L1 has a name. Its name is StableZK. This is the post where we get specific about the part of bank resolution that already works and that crypto has refused to import for fifteen years.
When I served at the FDIC, my office sat down the hall from the people who run resolution. They keep the receivership playbooks for the banks the agency closes. Every one of those playbooks has, on its first page, the same two columns. On the left, in priority order, are the classes of claim against the failed institution. On the right is the source the recovery comes from. Insured deposits at the top. Senior unsecured below that. Subordinated below that. Equity at the bottom, with a footnote that says “if anything is left.”
You can change the columns over decades through legislation. You cannot change them on the day the bank fails. The order being known and unchangeable is the entire reason an FDIC receivership doesn’t trigger a panic that destroys the next three banks down the street. Depositors don’t run because they know their column. Subordinated holders don’t sue because they know their column. Equity holders absorb because they always knew they were the column at the bottom.
It is the part of bank resolution that works best.
It is also the part crypto has refused, for fifteen years, to import.
What’s on the table
The L1:
StableZK. Three asset classes:szUSD(dollar-pegged),szBOND(yield-bearing junior debt),SZK(protocol token, equity-shaped)The waterfall:
szUSD → szBOND → SZK. Senior to junior to last. Immutable in code. Cannot be reordered by governanceThe floor:
130%minimum collateral ratio. Cannot be lowered by governance, ever, periodWhat governance can touch: trigger thresholds within published bounds, fee schedules within published bounds, parameter spaces with explicit ceilings
What governance cannot touch: the order of the waterfall, the floor, the
15%SZK collateral cap, the bounded-dilution mathCAMELS: the supervisory rating system that’s supposed to evaluate this kind of thing for actual banks, doesn’t, and I have publicly said needs a refresh
❦ ❦ ❦
The problem
A bank run starts when depositors are not sure which column they’re in.
That sentence is doing more work than it looks like. The mechanism of a bank run is not greed and it is not panic. The mechanism is uncertainty about loss absorption priority. If I know with certainty that I am insured, I do not run. If I know with certainty that I am uninsured, I run early — but I run only once, and the second-mover doesn’t accelerate me. If I do not know which I am, I run, the next person sees me running, and the line outside the building is now longer than the staff inside it.
This is why deposit insurance works. Not because it covers all possible losses — it doesn’t, and it isn’t supposed to — but because it makes the uncertainty go away for the class of holder who would otherwise drive the panic. Insured depositors know their column. They walk past the building. The run is contained to the columns where loss absorption was always going to happen.
Now look at what crypto has done with this for fifteen years.
The DAO. June 2016. A reentrancy bug drains roughly a third of the contract. The community holds an emergency vote on whether to hard-fork the chain to reverse the theft. The fork passes. The fork creates Ethereum and Ethereum Classic, which is to say it creates two chains because the loss absorption rule was decided in a vote after the loss happened. There was no published column. There was a debate.
Terra / UST. May 2022. As the peg breaks, governance proposals fly. Burn UST. Mint LUNA. Halt LUNA. Restart the chain without the bad actors. Each proposal is an attempt to write the loss absorption rule under fire. The market prices the debate, not the protocol. The debate is the run accelerant.
The various stablecoin emergency-power clauses written in the founding documents of basically every algorithmic and partially-algorithmic stablecoin in the post-Terra wave. They all read the same way. Article XII: In the event of a sustained loss of peg, the foundation may, at its sole discretion, deploy emergency mechanisms including but not limited to… The reader stops at “sole discretion.” Sole discretion is the opposite of a published column. Sole discretion is “we will figure out who absorbs after we see how bad it is.” That language is calibrated to make the writers feel safe. It makes the holders run.
Here is the part I want you to read precisely.
Ambiguity about loss absorption priority is the run mechanism. Not the trigger. The mechanism. A protocol with an immutable waterfall and a 5x worse credit profile is more run-resistant than a protocol with a 5x better credit profile and a discretionary one. The credit profile sets how often the run starts. The waterfall sets whether the run reaches second-mover scale. Most projects spend ninety-five percent of their attention on the first and almost none on the second.
CAMELS, the supervisory rating system the U.S. uses for chartered banks, doesn’t catch this either. C is capital adequacy. A is asset quality. M is management. E is earnings. L is liquidity. S, added in 1996, is sensitivity to market risk. Six letters. Five of them measure how the institution is doing under conditions where the resolution playbook is an afterthought. The resolution-readiness of the playbook itself is not a CAMELS factor. I have publicly argued the rating needs a refresh because the thing that actually predicts a panic is the credibility of the resolution path, and we don’t measure it. Crypto has the same problem in a more acute form, on a faster clock, with no examiner.
The decision
StableZK has three asset classes, in published priority order, with the order written into the protocol such that no governance call can rewrite it.
szUSD — the dollar-pegged asset. Senior. Holders of szUSD are made whole first in a resolution event, to the extent of available collateral. This is the column the depositor is in. The reason szUSD can carry a credible peg is that holders know, with the same certainty an insured depositor knows about FDIC insurance, that they are not the column that absorbs.
szBOND — the yield-bearing junior instrument. Subordinated. Holders accept loss absorption ahead of szUSD in exchange for yield. This is the column the senior unsecured creditor is in. szBOND exists, in part, to be a credible loss absorber so that szUSD does not have to be. A protocol without an instrument like szBOND is a protocol whose dollar-pegged asset is the first absorber by default, which is a protocol whose dollar peg is implicitly junior to its own token. That is exactly Terra’s mistake.
SZK — the protocol token. Equity-shaped. SZK absorbs last and is the dilutive instrument in Layer 4 of the GCSR ladder from the previous post. Holders of SZK are buying the upside of the protocol’s success and the corresponding obligation to absorb the downside of its failure. This is the column the equity holder is in. They always knew.
The waterfall is szUSD → szBOND → SZK. The order is in code. There is no admin function that can reorder it. There is no governance proposal that can amend it. The only way to change the order is to fork the chain — which, like the Bitcoin supply curve, is not a parameter change but an exit from one network and the start of another. That is the right cost for changing a rule that load-bearing.
The floor is the 130% minimum collateral ratio. New issuance below that ratio is rejected by the protocol. The floor is in code. Governance cannot lower it. Governance can adjust above it — within published bounds — but the floor is the floor.
The 15% SZK collateral cap from the previous post is the same kind of constraint. In code. Above the cap, governance cannot allocate more of the protocol’s own token to back the dollar-pegged asset. Below the cap, governance can flex within bounds.
What governance can touch is, deliberately, a small set: trigger thresholds within published bounds, fee schedules within published bounds, parameter spaces with explicit ceilings. The full list is in the cookbook. The principle is the one Bagehot would recognize. The ladder rungs and their order are out of the room. The room can vote on details.
Why immutable in code beats immutable on paper
Article XII of a foundation charter can be amended by the foundation. Smart contract code with no admin function cannot. This is the substantive difference between a written rule and a rule that has been removed from the room.
Bitcoin’s monetary policy works for the same reason. There is no admin function on the supply curve. The 21M cap is enforced not by foundation discipline but by node software that rejects blocks that mint more. A hard fork could change it. A vote cannot. The cost of changing the rule is the cost of forking the network — which is to say, the cost of replacing the rule is the cost of replacing the network. That cost is the credibility.
The waterfall in StableZK works the same way. There is no governance path that reorders szUSD and SZK. To do it, you would have to fork. The cost of forking is the cost of the credibility you would lose by doing it. The room cannot weigh that cost in a panic and the room is structurally barred from trying.
This is the part of bank resolution that crypto has refused to import. The legislative half — the columns being written down — yes, sometimes, on paper. The structural half — the columns being out of reach during the event — almost never. Almost never is the part that matters. Almost never is what the market prices.
What this looks like under the post-quantum decision
Every governance call carries a signature. If a future quantum capability can forge those signatures, an attacker with a forged governance vote in their pocket can in principle execute any move governance is authorized to make. That is the threat surface of a governance system.
The waterfall being out of reach to governance is therefore also out of reach to an attacker who has compromised the governance signing primitive. The 130% floor is out of reach. The 15% SZK cap is out of reach. The order of szUSD → szBOND → SZK is out of reach. A successful PQ attack on governance can change parameter spaces, fee schedules, trigger thresholds — within published bounds — and not the bounds themselves.
This is not a substitute for migrating governance signatures to PQ primitives. We are doing both. It is a structural defense in depth: the things that matter most are out of governance’s reach, so they are out of a compromised governance’s reach.
What this isn’t
This is not a claim that no rule should ever be changeable. The cookbook describes a small set of governance perimeter changesthat require both a supermajority vote and a long timelock — measured in months, not blocks. Those changes are the legislative half. They are slow on purpose. They cannot be deployed under fire.
It is not a claim that the order I picked is the only correct one. I argue with myself about whether szBOND should be one tier or multiple — whether there should be a senior subordinated and a junior subordinated, the way bank capital structures usually have. The cookbook lays out the case for and against. I landed on one tier because the marginal credibility of more granularity didn’t beat the marginal complexity. Reasonable people disagree.
It is not a claim that immutability is free. Immutability cuts both ways. A bug in the waterfall code is also unfixable by governance. The mitigation is that the waterfall is a small, audit-rich, formally-verified piece of code with a deliberately narrow surface area. Narrow is the operative word. The waterfall does one thing — distribute available collateral in priority order — and it does that thing in fewer than a thousand lines of consensus-critical code. If a system needs ten thousand lines of immutable code, the system is wrong before the immutability is wrong.
See also
Post 1 — Inside the Quantum Window. The decision that forced everything.
Post 2 — Bagehot Was Right. The five-layer escalation ladder that produces the waterfall as its terminal rung.
Post 4 — Privacy and Compliance Aren’t Enemies. Why the same logic — small load-bearing rules, taken out of governance’s reach — applies to the regulatory perimeter.
Cookbook Ch. 5 — The Resolution Waterfall. The contract surface, the audit story, the formal-verification posture, the FAQ on edge cases.
Closer
I’m not selling a token in this series. I told you in posts one and two and I’m telling you now. The protocol token (SZK) exists in the design because the dilutive backstop needs something to dilute. There is no presale running against the run of these posts and no allocation being asked for at the end. If that changes I will tell you, in plain text, in the post where it changes, before the rest of the post.
Pick a recipe. Read your stablecoin’s resolution language. If the document you read uses the phrase sole discretion, the protocol you hold has no published column. The market will price that. Print this post and hand it to the team that runs the protocol. Ask them to publish the column.
If they can’t tell you which column you’re in, you already know.
— Sultan
