Boomerang For the threat
beyond the keys

Coercion-aware cold storageKeys can be hardened against theft. The people holding them can still be forced to use them. Boomerang is designed to keep a forced withdrawal from becoming a predictable handover, preserving a live path to intervention before the funds can move.

How it works Support Boomerang
01 — Why Boomerang

A secure key can still be used under force

Physical coercion changes the custody problem from stealing a key to commanding a withdrawal.

Multisig, geographic separation, and isolated devices can frustrate remote theft. Physical control can turn those same safeguards into a sequence the attacker knows how to complete: gather the signers, approve the transaction, and leave with a verifiable payout.

Boomerang is built around the interval conventional custody leaves unused: after a withdrawal is demanded, but before it can be signed. It turns that interval into an active part of the defense.

Current position

Active development · public protocol design · Rust proof of concept

The protocol remains in design. The public specification and Rust proof of concept make that work inspectable while parameters, devices, human factors, and response operations are explored alongside it.

02 — Why time matters

Before payout, there is still room to act

A window before payout matters only if someone can recognize danger and act within it.

A 2024 peer-reviewed study of wrench attacks documented physical attacks targeting cryptocurrency users. In two reported cases, victims were forced to initiate transfers, but a 24-hour exchange delay and verification gave them time to flag and stop the transfers before attackers received all the funds.

Those cases do not prescribe a protocol, but they demonstrate the principle: withholding final payout can matter when a usable response path exists. A 2026 TRM Labs and Metropolitan Police framework adds operational context for the coordinated response such threats require.

03 — The mechanism

The finish line stays private

The current design coordinates five custodians, each with a trusted device called a Boomlet. Their approval begins required rounds; it is not a Bitcoin signature. A prearranged Search and Rescue service (SAR) receives encrypted state as those rounds progress.

  1. 01 — Confirm Confirm the exact transaction

    Each custodian reviews the same unsigned transaction. The resulting approval authorizes protocol progress; it is not yet a Bitcoin transaction signature.

  2. 02 — Signal Keep a protected signal in the loop

    Every required round carries encrypted state to the custodian's prearranged SAR. Safe and duress inputs produce the same kind of protocol-visible artifact, but the physical input itself can be distinguishable to someone watching.

  3. 03 — Progress Let each device set its own horizon

    Each Boomlet draws a fresh private progress threshold for the withdrawal. No participant can inspect it in advance or shorten it on command.

  4. 04 — Withhold Unlock signing only at completion

    Validated rounds advance the devices independently. Signing remains out of reach until all five are ready, while any activated response proceeds in parallel.

Boomerang in three lanes: attacker, protocol, response A timeline read left to right in four stages — approve, commit, digging, signing — across three lanes. Attacker lane: at approve, the attacker controls all five signers and forces a real withdrawal; at digging, the attacker must hold control and coordination through an unknown finish; at signing, the attacker must then sign, verify, exfiltrate the payout, and escape. Protocol lane: at approve, the exact transaction ID is confirmed on an air-gapped Secure Terminal and five TxApprovals are verified; at commit, each TxCommit carries an encrypted duress placeholder to SAR; at digging, five fresh private thresholds are drawn that nobody can read, lower, or command; at signing, all five are reached and five-of-five signing becomes available. Response lane, which proceeds asynchronously: at commit, SAR verifies commits and signs over the exact placeholder; at digging, every ping carries a fresh placeholder SAR must acknowledge; at signing, a durably activated response may proceed asynchronously. The digging stage is highlighted because its duration is private and unknown. 1 · APPROVE 2 · COMMIT 3 · DIGGING 4 · SIGNING ATTACKER PROTOCOL RESPONSE (ASYNC) Controls all five signers. Forces a real withdrawal. Must hold control and coordination through an unknown finish. Then sign, verify, exfiltrate the payout, and escape. Exact TxID confirmed on an air-gapped Secure Terminal; five TxApprovals verified. Each TxCommit carries an encrypted duress placeholder to SAR. Five fresh private thresholds. Nobody can read, lower, or command them. All five reached: five-of-five signing becomes available. SAR verifies commits and signs over the exact placeholder. Every ping carries a fresh placeholder SAR must acknowledge. A durably activated response may proceed asynchronously. TIME
Three lanes across one withdrawal. Private completion thresholds keep final signing unavailable while required progress can carry duress state to a prepared response.

An attacker may control the people and equipment, but cannot command the exact finish. Until all five private thresholds are reached, there is no signable payout; the protocol reveals neither the thresholds nor which round will complete the withdrawal.

Each unfinished round forces another decision: continue controlling the participants, equipment, and services without a payout, or abandon the attempt. The same required traffic keeps the protected channel active, allowing a duress signal to reach a prepared responder while signing remains unavailable.

That opportunity depends on protected input, trusted devices, and a responder prepared to act. Protocol traffic is designed not to reveal whether duress was signaled; the physical interaction can, and delivery of a signal does not guarantee intervention.

04 — The attacker's decision

Control gets more expensive before it pays

Each round that ends without signing asks the attacker to continue without proof that the next one will be the last.

While signing remains unavailable

  • There is no signed payout to verify or take
  • All required people and equipment must remain under control
  • The operation must stay coordinated across five custodians and the withdrawal services
  • Required traffic keeps the protected response channel open
  • Time, exposure, and operational cost continue to accumulate

The outcomes Boomerang is designed to make possible

  • Deterrence before a compatible attack begins
  • Abandonment when maintaining control no longer justifies continuing
  • Interruption before signing, exfiltration, or escape
  • An operational opportunity for a prepared response to reach the people involved

The result still depends on the people, the environment, and the response plan. Boomerang is designed to keep an immediate payout from deciding the outcome—and to prevent time from belonging entirely to the attacker.

05 — Current work

Designing the system as a whole

The protocol is being designed alongside the people, devices, services, and response operations it depends on, because each layer shapes what the others must do.

  • Human factors and input privacy

    The duress interaction must work under stress and protect the user's response from physical observation. UI/UX, accessibility, and human-safety partners are central to this work.

  • Parameter calibration

    Private threshold ranges, duress cadence, freshness rules, and service timing need simulation and measurement as one coupled system.

  • Target hardware

    Boomlet and Secure Terminal work must validate randomness, key protection, side-channel resistance, performance, endurance, and recovery on the devices that will enforce the design.

  • Response operations

    A Search and Rescue role needs credible partners, lawful authority, clear routing, privacy protection, practiced escalation, and a response plan designed around human safety.

  • Liveness and fallback

    Peer loss, service outages, device recovery, rollover, and fallback paths must preserve the intended economics without turning a failure into an indefinite and unsafe ceremony.

06 — Design path

How the design is taking shape

  1. Active Protocol design

    The public specification, security models, diagrams, and open questions continue to evolve together in the design repository.

  2. Executable exploration Rust proof of concept

    The proof of concept tests ideas about the setup and withdrawal roles, feeding what it reveals back into the protocol design.

  3. Current focus Simulation and parameters

    Dynamic modeling is being developed to explore how progress, cadence, and timing profiles behave together.

  4. Being defined Devices and operations

    Boomlet hardware, the Secure Terminal, networking, response services, fallback procedures, and product surfaces are being defined with the protocol—not after it.

07 — Work with us

Review, question, or support the design

Protocol and security review, hardware expertise, emergency-response experience, high-stress UI/UX work, economic modeling, and financial support can all strengthen Boomerang.

A question, critique, relevant experience, introduction, or note of support is enough to start a conversation.