Money Without a Master Key

This is the last post in the series. The hand-off to the long-form cookbook on sultanismyname.com. The shape of what’s there, the shape of what’s still open, and one number I want you to carry…

If you have read all five posts that came before this, you have the argument. The cryptographic window is closing. Stability is a credible commitment to escalate. The waterfall has to be immutable in code. Privacy and compliance aren’t enemies. The industry’s tradeoffs are mostly artifacts of older constraints. StableZK is the L1 I built to take all of those seriously at the same time.

This post is short. It does three things.

It tells you what’s in the cookbook on sultanismyname.com that the substack series didn’t have room for. It names the open problems I’m still arguing with myself about. And it asks you, one last time, to pick a recipe.

What’s in the cookbook

The full bounded-dilution proof, including the worst-case scenarios with the parameter table and the math that produces the 43.75%number from posts two and three. The substack version was a summary. The cookbook version is the proof, the assumptions the proof depends on, and the cases where those assumptions might break.

The phased launch architecture. Months 1 through 6 cap the protocol at $50M of supply with 200% collateral ratios and zero SZK in the collateral mix. The cap and the ratio relax across published phases as specific stability criteria are met — diversity of collateral, depth of liquidity, time at peg, count of independent integrations. Each phase has a written exit criterion. The cap is not relaxed by governance vote. It is relaxed by meeting the criterion in observable on-chain data.

The cold-start story. The Stability Reserve Fund is empty at genesis. SZK has no price. Collateral diversity is minimal. The phased launch architecture is the answer to that, and the cookbook chapter spells out exactly what the protocol looks like in week one (cap binding, single high-quality collateral, no Layer 4 dilution available, conservative trigger thresholds), week twelve, and month six. There is a separate recipe on what not to do during cold start, which is most of what other projects have tried.

The cryptographic migration table. Component by component, primitive by primitive, status as of April 2026. What’s production today. What’s hybrid-ready in the next eighteen months. What’s the destination. Where the migration is hard and where it’s mechanical. Which signatures are most exposed to harvest-now-decrypt-later and which get the front of the queue.

The regulatory architecture, per relevant jurisdiction. The U.S. picture. The EU picture (MiCA-shaped). The UK picture. The Singapore picture. The G20 surface. What’s a design choice and what’s a legal question requiring counsel in venue. Which regulators I expect to be early movers and which to be slow. None of this is legal opinion. All of it is what I would tell my own board if I were standing this up.

The recipe index. Every design decision in StableZK as a numbered cookbook recipe. Problem, Solution, Discussion, See Also. This is the part the engineers will print and the part the policy people will quote. It is the load-bearing artifact of the document.

The FAQ. Every question I have already been asked, answered plainly. Why an L1 instead of a rollup. Why this isn’t Penumbra or Aztec or Maker. What happens at Q-Day if Phase 3 hasn’t shipped. Why the migration isn’t done. Whether this is competitive with USDC or complementary. Whether a central bank could really back a non-CBDC instrument like this. Each gets a paragraph. Each is honest.

What’s still open

The cookbook is more honest than the series has had room to be. Three open problems are worth naming in this post directly.

Fee-only security in the long run. The protocol’s economic security model has block rewards that taper across the first sixteen years and then approach zero. After that, the network’s security depends primarily on transaction-fee revenue. This is structurally similar to the question Bitcoin will eventually face when its block reward halves below the level that pays for security at then-current attack costs. The question is whether the fee surface produces enough revenue, distributed across enough validators, to keep the security budget above the attack budget. I have models that say yes under reasonable assumptions about adoption and transaction value. I have other models that say maybe. Yes and maybe are not the same answer. This is the open problem I am most willing to be wrong about and most actively working on. The cookbook chapter on long-run economic security lays out the assumptions, the sensitivity analysis, and the proposed monitoring framework. It also lays out what we’d do — concretely, in code — if the fee surface didn’t produce enough by year ten or twelve. Saying we will figure it out is the failure mode posts two and three were about. Saying here are three pre-committed responses, here are their trigger conditions, here is what triggers each is the work I owe.

Cross-chain ZK production-readiness. Phase 1 of the bridge architecture uses validator committee attestation as a transitional trust model. That is the same trust model the L1 itself uses for consensus, so we are not introducing a new trust assumption — but the goal is full ZK verification on the peer chain, which is not production-ready as of this writing across the chains we care about most. Estimated 12 to 18 months out. The cookbook chapter on cross-chain primitives is honest about which legs of the bridge are ZK today, which are committee, and which are hybrid. If you read that chapter and conclude the bridge isn’t where you’d like it yet, you and I are reading the same document the same way.

SZK reflexivity at Layer 4. The 15% cap closes the Terra loop in the worst-case math. It does not eliminate every reflexive dynamic in markets that don’t follow the worst-case path. In particular, dilution at the cap can interact with SZK’s own price discovery in ways that the static model can’t fully bound. The cookbook acknowledges this, characterizes the residual risk, and proposes a set of empirical tests we’d run in production to detect reflexivity early. Detect early is not the same as prove it can’t happen. I am not pretending it is.

There are other open problems. These three are the ones I want a smart skeptic to push back on. If you push back on any of them and tell me something the cookbook hasn’t already considered, I would like to know.

The number I want you to carry

If you forget every other parameter in StableZK, carry the 15% cap.

The cap is the difference between a ladder and a ramp. It is the parameter that closes the circular-backing failure mode that has eaten every algorithmic stablecoin to date. It is the parameter that produces a bounded worst case instead of an unbounded one. It is, structurally, the most important number in the design.

Every other parameter is calibration. The cap is the principle.

See also

• Posts 1 through 5 — the argument.

• Cookbook on sultanismyname.com — the receipts.

• GitHub — the code, the test suite, the formal verification artifacts, the audit reports.

• The whitepaper PDF — for the strict cryptographic specification.

Closer

I’m not selling a token in this series. I told you in the first post and have repeated it in every one. There has been no allocation raised against the run of these posts. If and when that changes, I will tell you in plain text in the post where it changes, before the rest of the post. The fact that this line is in every post is the point. Trust is the cumulative absence of betrayal. The right time to start writing it down is at the start.

Pick a recipe — fork it, send it to your CFO, send it to your CISO, send it to your regulator, write a counter-recipe, build a different ladder, build a different waterfall. The point of the cookbook is not that this is the only way to do it. The point is that there is a way to do it, that the tradeoffs the industry has been treating as inviolable are not, and that the next currency we ship had better not have a master key.

Money without a master key is not a slogan. It is a set of constraints that compose, that have a working reference implementation, and that the current cryptographic generation makes possible for the first time in financial history.

Pick a recipe. Act on it this week.

— Sultan