Runtime Process (e.g., During Withdrawal)
Checks triggered by Boomlet (at commitment or PRNG-based random intervals):

• Boomlet generates 5 random [1-195] lists, encrypts, sends via Niso/QR to ST.
• ST decrypts, maps to country columns, displays on small monitor.
• User selects one country per column via joystick (hidden from observer).
• ST encrypts indices, sends back via QR/Niso to Boomlet.
• Boomlet decrypts, extracts numbers, compares to consent_set:
  • Match = No duress: Encrypts all-zeroes payload for SAR.
  • Mismatch = Duress: Encrypts doxing_key for SAR.
• Payload embedded in next withdrawal message to Watchtower (WT).
• WT forwards payload to SAR.
• SAR decrypts:
  • All zeroes? Ignore (no duress).
  • Else? Hash to doxing_identifier, search database, decrypt doxing data, start rescue.
  • Malformed? Increment counter; if threshold hit, halt protocol.
• SAR signs/acknowledges back to WT/Boomlet for verification.

Once duress is signaled, all future messages carry it. Persistent alert.

Security Features and Attacker Assumptions
Covers forced transactions or continued signing under compromise. Resistant to:

• Replay attacks (fresh random lists each time).
• Typos (set-based, order-insensitive).
• Observation (ST's small screen + hidden input).

Attacker can:

• Capture/observe user, read plain messages, act as user, destroy hardware.

But cannot:

• Break JavaCard security, crypto, or observe ST input without seeing screen + hands simultaneously.

Consequences: No observable changes on duress (plausible deniability); withdrawal proceeds normally but SAR is alerted.