Review of Spark's trust model

Analysis of pinned public code and one custom mainnet experiment. The optimized exit was still pending at the recorded September 11 checkpoint. These measurements are not a benchmark for every wallet or proof of a production operator outage.

1. Code-path analysis

   One operator can block the preparation that makes exit practical

   The reviewed consensus flows require every configured operator to prepare, even though signing uses a two-of-three threshold. Optimization relies on a cooperative SSP and on claiming replacement leaves through an all-operator flow. A user already facing refusal cannot assume they can consolidate or renew their way into a better exit.

   Evidence boundary. This applies to fresh preparation in the reviewed flows, not every API version or a failure after the commit decision. Production outage behavior was not tested. A complete presigned exit needs zero operators.

   All-operator selection · Prepare failure and rollback · Claim consensus · Swap and counter-transfer claim

2. Observed integration failure

   A successful export can still leave the exit unusable

   After the live optimization, two of ten available leaves had incomplete ancestry in the stock SDK export, including the 65,536-sat leaf. Custom parent-ID queries repaired the backup while an operator was reachable. If missing data cannot be obtained during an outage, the seed alone does not supply that transaction history.

   Evidence boundary. This is the pinned SDK result for this wallet. Other saved copies, willing data holders or confirmed ancestors may help; incomplete export does not establish permanent loss. The repaired JSON was about 459 KB, so this is not evidence that mobile storage is infeasible.

   Sanitized mainnet observations and before/after quotes · Best-effort export · Pedigree fetch

3. Mainnet swap; subsequent planner quote

   Even successful optimization did not make the whole balance economical to exit

   The live swap reduced 38 leaves to 10 without reducing the 89,569-sat balance. At 1 sat/vB, the native profitable selection still excluded eight leaves totaling 7,649 sats, about 8.5% of the balance. The selected principal improved from 65,536 to 81,920 sats, but selection is not receipt of spendable Bitcoin.

   Evidence boundary. The excluded value is not proved lost. Different fees, ancestry or recovery methods can change the result. The selected optimized exit had not completed at the recorded checkpoint.

   Sanitized mainnet observations and before/after quotes · Economic selection

4. Signed mainnet plan

   The user needs Bitcoin outside Spark to recover Bitcoin inside Spark

   The tested path requires an external Bitcoin fee reserve. The stock funding quote requested 5,228 sats against our 4,976-sat reserve. Custom allocation omitted optional sweep headroom and made the signed plan fit. Its planned fan-out and CPFP fees total 4,335 sats, excluding any later optional sweep. A consumer cannot assume the nominal Spark balance can pay these upfront costs.

   Evidence boundary. These are planned fees at 1 sat/vB, not all confirmed expenditure. A sponsor could supply funding but creates an additional availability dependency. Other presigned exit variants have different economics.

   Sanitized mainnet observations and before/after quotes · Funding construction and headroom

5. Observed transaction timelocks

   Recovery can mean weeks without the selected money

   The two selected paths retain 1,200 and 3,200 blocks of relative waiting: approximately 8.3 and 22.2 days at ten minutes per block, plus earlier confirmation dependencies. Optimization reduced fragmentation but did not turn the exit into an immediately spendable withdrawal.

   Evidence boundary. Block-time estimates are not deadlines. One replacement shortened its prior 2,400-block wait to 1,200 blocks; this is favorable evidence, but the denomination optimizer does not guarantee favorable replacement history.

   Sanitized mainnet observations and before/after quotes · Optimizer requests denominations

6. Mainnet observation and SDK failure handling

   Optimization itself temporarily ties up funds

   Available-balance samples were zero for roughly 23 seconds during the 23.7-second swap. The SDK can also defer claiming the counter-transfer after the original swap has begun. A phone losing connectivity must reconcile that pending operation before claiming the money is available or recovery preparation is complete.

   Evidence boundary. Temporary reservation is not theft or loss. An offline smaller-batch simulation preserved 65,536 sats outside the swap; it was not a live concurrent-payment test. Cancellation between rounds does not reverse an already submitted swap.

   Sanitized mainnet observations and before/after quotes · Reservations and cancellation · Deferred counter-transfer claim

7. Implementation requirement; dated wallet review

   The application must deliver a recovery system, not just expose an SDK call

   A usable phone flow must preserve current recovery state, fund fees, broadcast dependent packages, handle timelocks and conflicting variants, and resume across suspension, restarts and days of confirmations. Our optimized plan contains 29 Bitcoin transactions. The reviewed consumer-wallet surfaces did not demonstrate this complete flow, and our custom desktop tooling does not fill that product gap.

   Evidence boundary. Mobile implementation is possible in principle. SDK primitives and durable storage are meaningful groundwork. The wallet finding is limited to the dated reviewed versions and public surfaces, not every present or future application.

   Dated consumer-wallet review · SDK leaves orchestration to the application · Sanitized mainnet observations and before/after quotes

8. Conditional stress analysis

   The emergency scenario removes the services used to prepare the favorable result

   Our favorable optimization happened with a working SSP and operators. If refusal starts first, the user must work with existing leaves and whatever valid recovery material was already saved. Higher Bitcoin fees can make additional leaves uneconomical, and service loss may also prevent normal payments. Routine cooperative performance therefore does not measure the cost of recovery during a service failure.

   Evidence boundary. No coordinated outage or mass exit was induced. This analysis does not quantify network-wide congestion, prove permanent loss, or show that operators can veto already valid Bitcoin transactions.

   Economic leaf selection · All-operator preparation · Sanitized mainnet observations and before/after quotes

When operators refuse or go offline

One operator refuses or is offline. Fresh all-operator preparation can fail despite two remaining signing shares. The reviewed end-to-end optimization cannot be assumed available.

Two operators refuse or are offline. Fresh all-operator flows fail and only one signing share remains, below the published threshold. Another SSP does not replace missing operator shares or state.

All three refuse or are offline. A user with complete valid presigned recovery material can still exit through Bitcoin with zero operators. A user missing required data cannot assume the seed can reconstruct it.

An outage does not force an immediate exit: users can wait for restoration. Preparation failures and long waits are not proof of custody or theft. The supported criticism is dependence on advance preparation and an unproven consumer recovery experience.

Evidence that limits this criticism. A real unilateral mechanism exists. Five selected leaves from the earlier mainnet attempt were subsequently found recovered as 72,370 sats; those funds were used in the new experiment. Who broadcast the earlier path is not established, and operator unavailability was not demonstrated on mainnet. The new optimization succeeded, while its subsequent exit remained pending at the recorded checkpoint.

Potential exculpatory factors · Download assessment and sources