Keys are not the whole target
Most cold storage asks whether an attacker can get the key. Boomerang starts with a different question: can an attacker force the key holder to participate?
Boomerang
coercion-aware bitcoin cold storage with integrated duress signaling
Current custody usually protects the bitcoin better than the bitcoiner.
Hardware wallets, multisig, air gaps, and timelocks can make key theft harder. They do not automatically make a forced withdrawal harder.
Multisig spreads keys, not pressure
Multisig helps when one key leaks or one signer fails. If enough signers can be pressured through a known ceremony, the withdrawal can still complete.
Predictable ceremonies become playbooks
A fixed signer set, fixed device routine, and known signing time give an attacker a script: gather the people, demand the steps, wait for signatures.
Recovery is not duress awareness
Timelocks and backups can keep funds recoverable. They usually do not give the human a private, repeated way to say: this withdrawal is happening under pressure.
Boomerang attacks the coercion schedule.
It does not claim to make coercion impossible. It makes the preferred withdrawal harder to rush, adds quiet duress signaling, and keeps a later recovery path.
Bounded unpredictability
Each Boomlet keeps a private mystery threshold. Withdrawal should eventually become possible, but not at a time known to the user, peers, Watchtower, or attacker.
Duress inside the normal flow
The Secure Terminal asks for human input during the ceremony. Safe and duress answers must keep the same outward control flow, while SAR receives a placeholder either way.
Attack economics change
The attacker must sustain control through an unknown number of block-coupled rounds and repeated checks. More time means more cost, exposure, and chance of intervention.
Recovery remains, but later
Deterministic fallback branches use normal keys and timelocks if the primary path fails. Operators must roll over before fallback becomes the easy path.
Boomerang is a distributed custody design, not one device.
The current profile has five peers. Each peer has local devices and state; external services coordinate liveness and rescue without holding spend authority.
Peer and User
A Peer is one joint custodian. A User is the human operating that peer. The current Boomerang primary path is a 5-of-5 regime: every peer must participate.
Iso and Niso
Iso is the offline environment for key derivation, setup, and final signing. Niso is the online environment for peer communication, Watchtower communication, and Bitcoin RPC context.
Boomlet, Boomletwo, and ST
Boomlet is the active secure element: boom key share, mystery, counter, and duress logic. Boomletwo is the inactive backup. ST is the air-gapped approval and duress interface.
WT, SAR, Phone, and Bitcoin
WT routes approvals, pings, pongs, placeholders, and signed fragments. SAR handles rescue signals. Phone registers encrypted rescue data. Bitcoin settles the final transaction.
Withdrawal is a ping-pong game before signing.
The simple path is: agree on one PSBT, bind every peer to one tx_id, run duress-capable rounds through WT, then sign only after every Boomlet is ready.
One output, two regimes
Funds sit in a Taproot output. The primary Boomerang branch opens after milestone_block_0. Later normal-key branches provide deterministic fallback.
Everyone commits to one tx_id
The initiator proposes a PSBT. Every peer verifies it, confirms the tx_id through ST, and WT starts the digging game only after all peers approve the same tx_id.
Ping-pong advances readiness
Each Boomlet sends signed pings with tx_id, block height, sequence number, and reached flag. WT validates them, returns pongs, and counters advance only under freshness rules.
Duress checks recur
At commitment and during digging, ST asks for the consent pattern. A mismatch means duress; Boomlet then encrypts SAR unlock material inside the same placeholder path.
Boomerang is not finished until the hard boundaries are specified.
The remaining work is not polish. It is exact protocol definition, hardware lifecycle, timing policy, service failover, and operational recovery.
Cryptographic profile
AEAD, KDF/HKDF contexts, nonce rules, domain separation, canonical serialization, wire format, and test vectors still need final specification.
Timing and chain policy
Mystery ranges, duress-check cadence, freshness windows, jump limits, reorg handling, and divergent Bitcoin RPC views need final rules.
Recovery and failure procedures
Timeout, retry, blame, WT/SAR failover, device replacement, rollover, and the full deterministic fallback ceremony are not yet production procedures.
Hardware and rescue reality
Boomletwo activation, anti-clone semantics, Java Card Boomlet, ST implementation, metadata privacy, jurisdiction, and real SAR response need design and testing.
Boomerang fits narrow, high-risk custody.
Its complexity only makes sense when physical coercion is a serious part of the threat model.
High-risk individuals
Publicly known holders, people in unsafe jurisdictions, and operators whose identity or wealth makes forced withdrawal credible.
High-value custody systems
Treasuries, funds, family offices, and governance groups that need an ultimate fallback when ordinary multisig ceremonies are too predictable under pressure.
Reviewers before users
Near-term value is inspection: Bitcoin engineers, secure-hardware builders, threat modelers, formal-methods reviewers, and safety UX researchers.
Teams designing safer custody
Even if never deployed, Boomerang forces custody teams to model timing, human safety, fallback drift, emergency signaling, and operational failure.
Boomerang is research, not a promise of rescue.
It can change incentives and create chances to signal distress. It cannot remove violence, guarantee SAR success, or justify using unfinished code with real funds.
Not production custody
The docs, TLA+ models, and Rust proof-of-concept are for review. They are not audited, finished, or safe for real funds.
Not duress-proof Bitcoin
Boomerang raises attacker uncertainty. It does not make people safe by itself. Hardware, ST, WT, SAR, peers, and operations remain load-bearing.
Not for typical users
Most users should choose simpler custody. Boomerang adds devices, services, ceremony, metadata, and failure modes for an extreme threat model.
Not a custody service
WT and SAR should coordinate and respond, not hold spend authority. The design remains non-custodial only if that boundary stays true.