The questions I have already been asked.

Yes. The reasons it is a Layer 1 rather than a rollup are in the timeline. Briefly: none of the load-bearing commitments — post-quantum durability, immutable resolution waterfall, threshold-encrypted ordering — survives a rollup architecture cleanly. Sovereignty is necessary for those properties.

A rollup's resolution waterfall is reachable by the settlement layer's social-layer governance; its PQ migration is gated by the settlement layer's primitive choices; its mempool design is constrained by what the settlement layer admits. The properties StableZK is built around require sovereignty.

Each of those projects solves a subset of the problems StableZK solves. Penumbra and Aztec have shielded transactions but not a stability mechanism. Zcash has shielded transactions but is not a stablecoin platform. Maker has stability but not privacy. None of them treat post-quantum migration as a structural commitment from the design phase. StableZK's claim is composition: stability and privacy and fairness and durability, built together, with the architectural commitments that make them coexist.

The high-value-operation signatures (governance, escalation, resolution) ship Phase 3 in Phase 2 of the migration timeline. The holder-facing proof system migration is staged with hybrid intermediary primitives that buy integrity through the migration window. No component is exposed solely to a Phase 1 primitive when Phase 2 ships. The ZK light-client bridge architecture is the longest-lead item; users with significant cross-chain exposure should plan for that.

Aggregate PQ signatures for validator consensus are a research-active area. STARK proof aggregation for consumer-facing applications is improving but proof sizes are still larger than the Phase 1 baseline. Hybrid construction is acceptable today; PQ-only end-to-end requires either further research progress or accepting performance trade-offs the project judges not yet warranted. The cookbook is explicit on the timeline and the constraints.

Both, depending on use case. For pure dollar-equivalent operations on regulated counterparties with established custody, USDC and similar custodial stablecoins remain the simplest available instrument. For applications where the user values default privacy, post-quantum durability, MEV-resistant ordering, or non-custodial loss-absorption guarantees, StableZK is built for that surface. The two coexist comfortably.

The architecture is built for that case. A central bank backing szUSD reserves with its own deposits is structurally a different arrangement from issuing a CBDC: the central bank does not issue the digital asset, does not control its supply, does not hold direct counterparty information about its users, and does not bear primary execution risk for transactions. Whether any specific central bank chooses to do this is a question outside the cookbook. The architecture supports it. The political question is the political question.

No. There has been no presale and there is no allocation being raised against this cookbook. If that changes I will say so in plain text in the post or section where it changes, before the rest of the post or section.

Open problem. Block rewards taper across the first sixteen years and approach zero thereafter. After that the network's security depends on transaction-fee revenue, and the question is whether the fee surface produces enough revenue across enough validators to keep the security budget above the attack budget. Models say yes under reasonable assumptions and maybe under more pessimistic ones. The cookbook lays out the assumptions and the proposed monitoring framework. Mitigations under consideration include modest perpetual issuance, fee-burn-with-floor mechanisms, and pre-committed parameter responses if monitored thresholds are crossed.

Open problem named in § 3.5. Phase 1 uses validator committee attestation as a transitional simplification; Phase 2 ZK light clients are 12–18 months out. Users with material cross-chain exposure should plan accordingly.

The bounded-dilution proof and the resolution-waterfall safety proofs are linked from the canonical cookbook on sultanismyname.com and from the GitHub repository. The whitepaper PDF carries the strict cryptographic specification.

No. The regulatory architecture in Chapter 6 is design, intended to inform implementation in collaboration with counsel in each relevant jurisdiction. Per-jurisdiction notes (§ 6.4) are the starting point for in-venue counsel, not the destination.