OpenTrail is pre-release research software and is not suitable for emergency-response dependency, safety-critical control, or protection of sensitive information.

Do not include credentials, private keys, channel secrets, precise private locations, or exploit details in a public issue. Prefer a private GitHub Security Advisory when that feature is enabled. Otherwise, contact the repository owner privately before sharing sensitive details.

• Emergency and priority features are supplemental aids, not guaranteed rescue services.
• The owner-approved V1 design permits pairing only from a verified unowned boot: the device automatically opens exactly one 60-second window, displays one fresh six-decimal-digit passkey locally, and permits one Bluetooth LE Secure Connections-only, MITM-authenticated passkey pairing attempt with bonding and an exact 16-byte/128-bit key. An owned boot is PIN-free and accepts only its saved authorized phone. V1 has no phone-replacement or lost-phone transfer path. Recovery is a destructive factory reset initiated either by the authorized app, after explicit in-app confirmation and without Heltec confirmation, or by the local 10-second hold/warning/release/short-press sequence. Both paths must erase and verify absence of all user data and BLE bonds before the device may restart unowned. Decision 0103 and DEVICE_FACTORY_RESET_V1 are current; OT-090 remains historical host evidence.
• V1 does not claim ownership rollback protection against factory reset, reflashing, invasive physical access, or restoration of old flash. A secure element or external monotonic component is not a V1 requirement.
• BLE phone authorization does not secure radio traffic. OT-091 freezes and host-tests the algorithm-neutral OTSL0/v0 two-node pairwise-unicast lifecycle/admission contract: a secret-free single-use invitation, mutual-authentication and matching-confirmation obligations, exact commit/activation, epoch-plus-one replacement with no old-epoch fallback, directional key/counter binding, replay-before-plaintext persistence, protected acknowledgements, and bounded retry/restart failure. OT-093 separately freezes an exact two-build pre-crypto baseline with no candidate or secure-LoRa adapter imported or executed. The historical OTCB0/v0 plan remains draft_blocked; OT-116 instead accepts a successor review and freezes a phased fail-closed plan. OT-117 and OT-118 populate all three API/configuration registries, OT-119 completes phase 0, and OT-120 accepts every retained candidate import/build anchor and completes phase 1. Current source/API/import counts are 3/3/3; Monocypher and mbedTLS/PSA remain structurally nonselectable. OT-121 grants bounded Phase 2 execution authority and records only a successful two-node libsodium local-primitives checkpoint; the receipt remains phase_two_complete=false with no Noise XK or radio result. Selection authority remains withheld. Decision 0003 still blocks every suite/library, handshake/KDF, and Packet V1 selection until the remaining exact-target benchmark work completes and a later explicit selection passes. No secure-LoRa implementation or physical acceptance exists.
• Packet v0, plaintext fallback, caller-supplied authentication Booleans, alias/name trust, random-nonce fallback, counter reuse, replay-state reset under the same key, unauthenticated acknowledgements, and post-activation old-epoch fallback are prohibited from a future protected-radio composition.
• Hardware test tools must redact node identities, keys, coordinates, PINs, and secrets.
• No firmware or hardware configuration should be described as secure or production-ready without documented threat modeling and validation.