The Resolution Waterfall
4 recipes.
The waterfall is what the GCSR ladder ends in. The principle: "we will figure it out in the moment" is the protocol design equivalent of "we will figure it out in litigation." Both produce predictable losses. The waterfall is the alternative — the pre-committed, code-enforced, governance-immune ordering of who absorbs loss when the system cannot defend the peg.
Three asset classes, in order. szUSD senior. szBOND subordinated. SZK absorbs last. The order is in code. The only path to changing it is forking the chain — running incompatible node software on a different network with a different state root. The cost of forking is the cost of the credibility being abandoned. That is the point.
-
A bank capital stack reframed in protocol form. The szBOND instrument exists in part so szUSD does not have to be the first absorber.
-
Immutable on paper is a charter article. Immutable in code is a smart contract with no admin function. The cost of forking is the cost of the credibility being abandoned.
-
Governance can change parameters within published bounds. Governance cannot change the order of the waterfall, the 15% cap, the 130% floor, or the bounded-dilution math.
-
Immutable code is unfixable code. The mitigations are formal verification, narrow surface, third-party audits, and a published incident response that includes forking the chain as the unhappy-path option.
Immutability cuts both ways. The mitigations — formal verification, narrow surface (§ 5.4), audits, and a published incident response that includes the option of forking the chain — are the unhappy-path equivalent of governance. Read § 5.3 for what governance can and cannot touch.