Review of Spark's trust model

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

4 sourcesEvidence reviewed through July 14, 2026

What the evidence shows

Technical and product details

  1. 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

  2. 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```
  3. 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

    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.
  4. 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.
  5. 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

  • Real mainnet exit packages were advanced without later Operator cooperation. The discrepancy concerns prior state acquisition, final-sweep completion, and economic accounting—not whether the package sequence began. 23

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.

1

Blink Weekly Brief

Blog or announcement · blink.sv · Live source · checked 2026-07-14

Open original source
2

case-study recovery state

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source
3

case-study Step 6

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source
4

case-study accounting

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source

How sources, absence findings, and limitations were evaluated