Thanks @bodhi for the question.

1. Liveness verification
   System liveness is continuously validated by comparing the latest block height reported by peers with the height observed by the watchtower. If the difference falls outside the acceptable tolerance range, the protocol treats the state as unreliable. During the active ping-pong phase, the step is rejected and does not advance progress. If detected before ping-pong begins, the protocol safely falls back and initiates fault attribution to preserve consistency and trust.
2. Hardware redundancy
   All critical hardware components are provisioned with a verified backup during the setup ceremony. This backup is designed to securely replace the primary device if needed, ensuring operational continuity without weakening the protocol’s security guarantees.

Both mechanisms are already accounted for in the roadmap and will be fully specified during the ancillary design and implementation phase, where detailed engineering and operational procedures are finalized. We are not there yet.

My bad @Signal312. Let me put all technicalities aside.

1. Imagine an enterprise holding significant Bitcoin reserves. Even with best-practice operational security, ultimate signing authority typically concentrates in a small group, for example, five senior managers controlling core keys.
2. That concentration creates a high-value human attack surface. Those individuals become prime targets for coercion attacks such as kidnapping, extortion, or physical threats, so-called “wrench attacks.”
3. A critical but often overlooked assumption behind coercion attacks is predictability. The attacker expects a clear, bounded path to success: force the key holders to sign a transaction and receive funds within a known timeframe. Traditional signing is deterministic; once coerced, the outcome is immediate.
4. Boomerang breaks this predictability. Signing is intentionally non-deterministic. Each signing key is a MuSig2 aggregate of two components: a conventional key and a hardware-sealed key embedded in a secure device. The sealed key is non-extractable and will only participate in signing after a multi-party verification protocol of unpredictable duration completes.
5. During this protocol, all key holders must repeatedly confirm transaction intent and indicate whether they are acting under duress. Independent external verifiers confirm system integrity and ensure duress signals are properly transmitted and acknowledged. If any required confirmation fails, signing halts.
6. Neither the key holders nor an attacker can determine exactly how long the withdrawal process will take. The delay is bounded but intentionally uncertain. Crucially, duress signaling is indistinguishable from normal protocol traffic to an attacker, and withholding responses prevents completion.
7. The practical effect is that a coerced withdrawal becomes unreliable, slow, and risky from the attacker’s perspective, potentially taking weeks or months, undermining the core incentive behind coercion.
8. Boomerang is not intended for everyday liquidity operations. It is designed as a strategic cold-storage layer for extreme threat scenarios; a defensive fallback when compromise, intrusion, or coercion risk is suspected.
9. It is particularly well suited for low-velocity reserves: funds that do not require rapid access but demand maximum protection against physical or social attacks.

Note: The full protocol includes additional safeguards and edge-case handling not covered in this high-level overview.

I hope this helps.

Protocol Description
Boomerang is a Bitcoin cold-storage protocol designed for high-value holdings, providing strong protection against duress (e.g., coercion or threats) without altering Bitcoin's consensus rules. It achieves this through a non-deterministic withdrawal process enforced by secure hardware, creating unpredictability in signing with embedded, plausibly deniable duress signaling and "search-and-rescue" (SAR) escalation. Funds are locked in a Taproot output with two spending regimes: a probabilistic "Boomerang" path using MuSig2 keys (including a non-backupable key in a Java Card applet) requiring 5-of-5 multisig, and a deterministic "normal" path with timelocks for fallback.

Entities

1. User / Peers: 5 entities that collaborate as the main key holders of the protocol. We name the peer from whose POV we explain the protocol, the user.
2. Iso: A stateless piece of software that is run on an isolated computing environment.
3. Niso: A stateful piece of software that runs on a non-isolated computing environment with access to a full bitcoin node and TOR network.
4. Boomlet: A java card applet that is installed and run on a java card.
5. Boomletwo: A java card applet that is installed and run on a java card, acting as the back up of Boomlet.
6. ST: Short for Secure Terminal. A tamper evident, air-gapped hardware used for trust minimization in communications between user and boomlet.
7. WT: Short for Watchtower. An online entity that manages coordination of the peers and act as one of the roots of trust to provide the heartbeat of the protocol which is the latest bitcoin block height.
8. SAR: Short for Search And Rescue. Is an online entity that receives encrypted doxing data from user and checks for the duress signal. Should it detect a positive duress signal, the SAR uses that signal to decrypt the doxing data and perform a search and rescue operation based on the aforementioned data. Since SAR's operations are mostly focused on physical security, this entity is jurisdiction dependent in order to comply with the pertinent use-of-force rules and regulations.
9. Phone: User's phone that registers with the SAR and provides encrypted dynamic and static data to the SAR.

Setup
The setup involves coordinated, secure steps among entities like the user, isolated environments (Iso), secure terminals (ST), watchtowers (WT), SAR providers, and hardware applets (Boomlet/Boomletwo):

• SAR Registration: User registers with SAR entities via an encrypted phone app, providing doxing data for potential rescue.
• Key Generation: In an air-gapped Iso, generate a normal mnemonic key and Boomlet applet creates MuSig2 shares plus a non-backupable boomlet key. Set duress consent via selecting 5 countries (exact match signals no duress).
• Parameter Agreement: Peers agree on timelocks (milestone blocks), and WTs via encrypted, signed TOR exchanges.
• Mystery Generation: Each Boomlet randomly selects a secret "mystery" threshold (steps in withdrawal) within a user-defined range.
• Backup and Sync: Create/verify a single backup applet (Boomletwo); synchronize keys, parameters, and fingerprints via WT for consistency.

This ensures no single party can predict or bypass the process, emphasizing tamper-evident hardware and opsec.

Withdrawal
Withdrawal is a collaborative, unpredictable multi-phase ceremony post-milestone_block_0, involving all 5 peers signing a PSBT:

• Initiation: One peer creates and shares the PSBT; all approve via ST and WT.
• Duress Check: Each peer selects countries; mismatches signal duress, triggering encrypted SAR payloads without altering behavior.
• Digging Game: A ping-pong loop of signed messages via WT, incrementing a counter until each Boomlet hits its secret mystery threshold (could take months due to randomness). Pseudo-random duress checks occur throughout.
• Signing: Generate/aggregate MuSig2 partial signatures offline in Iso; broadcast via WT.
• Fallback: If stuck (e.g., lost hardware), funds unlock deterministically after timelocks via normal keys.

The design prioritizes coercion resistance through unpredictability and deniability.