Unilateral-exit readiness
Blink's Weekly Brief described seed-only recovery and an unswept amount as received
Blink's Weekly Brief said the exit used only the seed with no Operators online and that 89,668 sats reached the destination. Its linked case study requires previously saved recovery state and records the selected exits as still awaiting refund maturity and final sweeping. 123
What the evidence shows
Technical and product details
- Published description
Blink's July 10 Weekly Brief said the exit was completed “using only the seed, with no operators online” and that 89,668 sats reached the destination. 1
Supporting material shown on this page
Blink Weekly BriefBlog or announcement · blink.sv · checked 2026-07-14 - Recovery-state requirement
The linked case study states that Operators must still be online when a complete, current recovery bundle is created; after they are offline, a seed alone cannot rediscover the current leaves. 2
Supporting material shown on this page
case-study recovery statePinned source code · github.com · checked 2026-07-14 Relevant lines from the pinned source · open raw file 22leaves cannot be discovered from the seed alone. The exit needs a **recovery 23bundle** — a JSON snapshot of the wallet's leaves and their ancestor 24transactions — refreshed while operators are still online: 25 26```sh 27make refresh-recovery-bundle SEED_FILE=../.spark-seed.txt BUNDLE=../recovery-bundle.json 28``` - Completion-status mismatch
The Brief said 89,668 sats reached the destination. Step 6 of the linked case study said the four selected exits were still waiting for refund maturity and described refund broadcast and sweeping as future operations. 13
Supporting material shown on this page
Blink Weekly BriefBlog or announcement · blink.sv · checked 2026-07-14 case-study Step 6Pinned source code · github.com · checked 2026-07-14 Relevant lines from the pinned source · open raw file 189After the loop finishes, each economical leaf's refund waits out its CSV 190timelock. Re-running the same `make recover` after maturity broadcasts the 191refunds; once they confirm, `make sweep` builds and signs one-input Taproot 192key-path spends from the refund outputs to any destination address, and 193`broadcast-sweep` pushes them as ordinary transactions. At the time of 194writing, this wallet's four economical exits are through their chains and 195waiting on refund maturity. - Source inconsistency
Earlier portions of the same case study use “confirmed,” “arrives,” and “reach” language. Its explicit “At the time of writing” checkpoint nevertheless records the refunds as unswept. This review uses that status checkpoint when distinguishing completed transactions from projections. 3
Supporting material shown on this page
case-study Step 6Pinned source code · github.com · checked 2026-07-14 Relevant lines from the pinned source · open raw file 189After the loop finishes, each economical leaf's refund waits out its CSV 190timelock. Re-running the same `make recover` after maturity broadcasts the 191refunds; once they confirm, `make sweep` builds and signs one-input Taproot 192key-path spends from the refund outputs to any destination address, and 193`broadcast-sweep` pushes them as ordinary transactions. At the time of 194writing, this wallet's four economical exits are through their chains and 195waiting on refund maturity. - Accounting distinction
Even as a projected destination output, 89,668 sats is not net economic recovery because 8,388 sats of CPFP fees came from separate on-chain bitcoin. 4
Supporting material shown on this page
case-study accountingPinned source code · github.com · checked 2026-07-14 Relevant lines from the pinned source · open raw file 111| **arrives at the destination address** | **89,668** | 112| dust in 18 uneconomical leaves, left behind in Spark | 9,888 | 113 114Spark exit and refund transactions are pre-signed with **zero fee** (fees ride 115the CPFP anchors), so each refund output carries the full leaf value; the only 116deduction from the wallet balance itself is the final sweep fee.
Product-level detail
What the reviewed Blink application exposed
The conclusions below are reproduced here so the reader does not need to open the separate implementation review. Each result remains limited to the named source snapshot, published binary, or public product surface.
Blink
Surface reviewed: public mobile source
The tracked app backup and restore paths center on the mnemonic; no complete recovery-bundle export and operatorless execution workflow was found. Blink's separate recovery repository labels mobile integration a proposed boundary.
Capabilities that were present: mnemonic backup and restore; ordinary Breez Spark wallet operations.
The separate Blink command-line recovery project is not treated as an in-app mobile workflow.
See versions, search method, artifact hashes, and full review limits.
Scope control
What this does not establish
Sources and excerpts
Primary sources
The relevant details and available source-code excerpts appear alongside the claims above. This list preserves the complete original-source trail for independent verification.
Blink Weekly Brief
Blog or announcement · blink.sv · Live source · checked 2026-07-14
case-study recovery state
Pinned source code · github.com · Pinned or archival · checked 2026-07-14
case-study Step 6
Pinned source code · github.com · Pinned or archival · checked 2026-07-14
case-study accounting
Pinned source code · github.com · Pinned or archival · checked 2026-07-14
How sources, absence findings, and limitations were evaluated