The data-availability dependency is real and worth stating exactly, so let's state it.
Operators never hold your key and can't move funds without your signature - that part is unconditional. Unilateral exit works through pre-signed refund txs that pay to a key only you control, and those txs plus their ancestors are the "leaf data" in question: your device co-signs them at claim time, ancestors come from a query. Until a wallet persists that data, forcing your funds on-chain depends on operator liveness. Grubles is right that no wallet ships this today. That gap is the entire reason I built and published this tooling instead of just claiming "non-custodial" in marketing copy.
What the dependency actually is, once you persist the data:
Bounded: everything covered by your last refresh exits without any operator, forever. Exposure is only what changed since then. With refresh wired into every claim, that window is one transaction.
Detectable: withholding means your refresh fails right after your claim succeeded. You notice, you stop receiving, you exit with what you have. - Compare a custodian, where withholding looks like normal operation until the withdrawal freeze.
So on the spectrum: weaker than Lightning, where your node holds channel state by construction. Much stronger than custodial, where they hold both keys and data and you detect nothing. "Self-custody of keys with a bounded, detectable data-availability dependency" is the honest label.
Wallets that don't manage that dependency for users are shipping the weak end of the spectrum. Mine included, today. That is what is being fixed, and the case study is the receipt that the exit half already works:
GitHub
spark-unilateral-exit/docs/mainnet-exit-case-study.md at main · blinkbitcoin/spark-unilateral-exit
Tools and guide for Spark unilateral-exit recovery - blinkbitcoin/spark-unilateral-exit
