cocottetech/@hardware/docs/IDEAS.md

# @hardware — Ideas

Capture log for hardware-product ideas in the cocottetech lineage. Newest first.
Status values: captured · exploring · committed · dropped.

---

## membership-wallet — bundled hardware wallet with global radio SIM
- **Date:** 2026-05-18
- **Status:** captured

### Pitch
A hardware wallet included as a standard-tier membership benefit. Built-in
global radio-network SIM gives it independent connectivity (no phone tether,
no wifi). Form factor and interaction model are **calculator-like** — physical
keypad, small display, deliberate haptic UX.

### Physical concept (credit-card form factor)

```
   ┌──────────────────────────────────────────┐
   │  ◉ cocotte                       ▒▒ SIM  │   <- radio status LED + eSIM mark
   │  ┌────────────────────────────────────┐  │
   │  │  0.0421 ₿        → @lou            │  │   <- e-ink display
   │  │  balance         peer / amount     │  │
   │  └────────────────────────────────────┘  │
   │                                          │
   │   ┌───┐ ┌───┐ ┌───┐    ┌─────┐           │
   │   │ 7 │ │ 8 │ │ 9 │    │  ÷  │           │
   │   ├───┤ ├───┤ ├───┤    ├─────┤           │
   │   │ 4 │ │ 5 │ │ 6 │    │  ×  │           │
   │   ├───┤ ├───┤ ├───┤    ├─────┤           │
   │   │ 1 │ │ 2 │ │ 3 │    │  −  │           │
   │   ├───┤ ├───┤ ├───┤    ├─────┤           │
   │   │ . │ │ 0 │ │ ⌫ │    │  +  │           │
   │   └───┘ └───┘ └───┘    └─────┘           │
   │                                          │
   │   [ MENU ]   [ ◉ SEND ]   [ = / CONFIRM ]│
   └──────────────────────────────────────────┘
        ~ credit-card footprint, ~3–4 mm thick
        ~ e-ink for battery life + sunlight readability
        ~ tactile keypad (no touchscreen — plausible-deniability calculator vibe)
        ~ NFC patch on the back for tap-to-pair peer transfers
        ~ eSIM + LTE-M / NB-IoT modem inside; antenna ringing the perimeter
        ~ universal Qi wireless charging (works on any iPhone/Android pad,
          any café dock — NO proprietary puck). Wired data port is
          optional / recovery-only; see Open questions.
```

Edge / back view:

```
   front:   [ display + keypad — looks like a pocket calculator ]
   back:    [ NFC tap zone ]   [ ◡ smooth pogo indent ]   [ serial ]
            (recovery QR window etched flush)
   edge:    (no port)                                   status LED
            charging is wireless — universal Qi, any pad
            optional pogo pads for factory recovery only
```

### Component layout — does it all fit, does it balance?

Card footprint: standard ID-1 / credit-card, **85.6 × 54 mm**, target
**3–4 mm thick**. Budget every external surface (front, back, edge)
plus an internal Z-stack of ~5 layers. Heavy / area-hungry components
get **stacked in Z** rather than fighting for X-Y real estate.

**Front face** (member-facing, calculator UX):

```
   ┌──────────────────────────────────────────────────────┐
   │ ◉ cocotte                              ▒ status LED  │  ← top status row
   │ ┌────────────────────────────────────────────────┐   │
   │ │            e-ink display  (~50 × 25 mm)        │   │  ← display
   │ │  balance  ·  peer handle  ·  amount  ·  code   │   │
   │ └────────────────────────────────────────────────┘   │
   │                                                      │
   │   ┌───┐ ┌───┐ ┌───┐                       ┌─────┐    │
   │   │ 7 │ │ 8 │ │ 9 │                       │  ÷  │    │
   │   ├───┤ ├───┤ ├───┤                       ├─────┤    │  ← 3×4 numeric +
   │   │ 4 │ │ 5 │ │ 6 │                       │  ×  │    │    1×4 operator
   │   ├───┤ ├───┤ ├───┤                       ├─────┤    │    membrane keypad
   │   │ 1 │ │ 2 │ │ 3 │                       │  −  │    │
   │   ├───┤ ├───┤ ├───┤                       ├─────┤    │
   │   │ . │ │ 0 │ │ ⌫ │                       │  +  │    │
   │   └───┘ └───┘ └───┘                       └─────┘    │
   │                                                      │
   │     [ MENU ]      [ ◉ SEND ]      [ = / CONFIRM ]    │  ← action row
   └──────────────────────────────────────────────────────┘
```

Front is the most pixel-budget-constrained surface. Membrane keypad
sits directly on the main PCB; e-ink display is laminated above. No
free area on the front to spare for the LED strip or piezo — those
move to edge / back.

**Back face** (the radio + power face — everything stacks here):

```
   ┌──────────────────────────────────────────────────────┐
   │  serial · cocotte ·······························   │
   │  ┌─────────────────────────────────────────────┐     │
   │  │                                             │     │
   │  │      NFC antenna loop ── outer ring         │     │  ← NFC + Qi coils
   │  │   ┌─────────────────────────────────────┐   │     │    stacked
   │  │   │                                     │   │     │    (flex multilayer,
   │  │   │      Qi v2.1 receiver coil          │   │     │     same X-Y zone)
   │  │   │      ( ~38 × 38 mm spiral )         │   │     │
   │  │   │                                     │   │     │
   │  │   └─────────────────────────────────────┘   │     │
   │  │                                             │     │
   │  │       NFC tap zone (this whole region)      │     │
   │  └─────────────────────────────────────────────┘     │
   │                                                      │
   │   ▣ recovery QR (etched, flush)        ◡ pogo indent │  ← smooth shallow
   │                                          (4–6 pads)  │    indent, flush pogo
   └──────────────────────────────────────────────────────┘
```

The Qi coil (~38 mm class) and the NFC antenna loop share the same
X-Y real estate because they're on **different flex layers** and run
at totally different frequencies (Qi ~100 kHz, NFC 13.56 MHz). Stack
order is engineered so neither blocks the other; this is the standard
trick on every card-form wallet that ships Qi today.

**Edge** (switch + status):

```
   top edge   :  ───── perimeter LED strip wraps all 4 sides ─────
   left edge  :  ◀── [ LOCK · SEND · RECV ] ──▶   ◉ piezo port
                       ░░░ (toggle pulse LED under detent)
   right edge :  status LED · cellular antenna feed point
   bottom edge:  (clean — no exposed metal, no port)
```

Charging is wireless (Qi), so the bottom edge has no port and stays
clean. Cellular antenna is a meandered trace along the inner side of
the card edge — antenna real estate is what makes the perimeter
ring useful for two things at once (radio + LEDs).

**Internal Z-stack** (top of card → back of card, ~3–4 mm total):

```
         ┌──────────────────────────────────────────┐  ← 0.3 mm — front shell
   1     │  front shell + membrane keypad overlay   │
         ├──────────────────────────────────────────┤
   2     │  e-ink display module                    │  ← 0.5 mm
         ├──────────────────────────────────────────┤
   3     │  main PCB — MCU · modem · secure         │  ← 0.6 mm
         │  element (EAL6+) · iSIM/eSIM · BLE/NFC   │    PCB + components
         │  controller · PMIC · piezo step-up · LED │
         │  drivers · supercap (SMD)                │
         ├──────────────────────────────────────────┤
   4     │  Li-Po pouch  (~40 × 45 × 1.0 mm,        │  ← 1.0 mm
         │   ~150 mAh, centered)                    │
         ├──────────────────────────────────────────┤
   5     │  multilayer flex — Qi coil + NFC loop    │  ← 0.4 mm
         │  + perimeter LED strip + piezo flex tail │
         ├──────────────────────────────────────────┤
   6     │  back shell w/ pogo indent + QR window   │  ← 0.3 mm
         └──────────────────────────────────────────┘
                          ≈ 3.1 mm  ──  fits the 3–4 mm budget
```

**Balance / centre-of-mass check:**
- Heaviest single component is the **Li-Po pouch** (~3–4 g). Placed
  centred so the card's CoM stays near geometric centre.
- Display is heavy-ish but mounted at the top half of the front;
  battery sits in the lower half of layer 4 to **counterweight**.
- Main PCB components (MCU + modem + secure element) are the densest
  silicon area — distribute around the edges of layer 3 rather than
  clustering, both for thermal and balance reasons.
- Piezo, the supercap, and the LED drivers go to the *corners* of
  layer 3 — naturally balancing each other off-axis.
- Perimeter LED strip + cellular antenna ring the whole card → mass
  is symmetric by construction.

**Does it all fit? Yes, with two tight spots:**
- **Qi coil vs. NFC antenna** share X-Y but live on different flex
  layers — solved (already shipping pattern). The risk is yield.
- **Front-face real estate**: keypad + display + action row + status
  row is exactly the front, with **zero margin** for adding more UI.
  Any future feature that needs front-face pixels (touch, fingerprint
  reader) means dropping a key or shrinking the display. Treat the
  front as **fully booked**.

Anything else added later — fingerprint sensor, second display,
solar trickle cells, larger speaker — has to come out of layer 3
(displace silicon) or grow the Z budget past 4 mm.

### Function
- **Retrieval surface for E2EE + crypto.** Holds the keys / recovery material
  needed to decrypt member content and authorize crypto operations. Framed
  as *retrieval*, not deep cold-storage.
- **Peer-to-peer instant transfers.** Two members with wallets can transact
  directly, calculator-to-calculator — punch in an amount, confirm, done.
  Settlement rides the radio mesh, not the member's phone or local network.

### Why it matters (membership angle)
- Standard-tier inclusion (not an add-on) makes it a defining benefit of
  joining, not a SKU. Hardware-in-the-box anchors membership identity.
- Independent radio = works in venues / tours / travel where phones are
  off, dead, or locked down.
- Calculator UI is **plausibly deniable**: looks like a calculator at a
  glance. Useful in environments where a "crypto device" would be a tell.

### Decided

- **Recovery model:** the platform holds a recovery share. Member loses the
  wallet → platform-held share + member identity proof restores access.
  Explicitly trades some sovereignty for member-friendly recovery,
  consistent with membership framing.
- **Pairing transport:** NFC. Tap-to-pair is the only introduction
  mechanism (no QR, no BLE-discover-in-the-air). Session channel that
  follows the NFC handshake is still TBD (BLE vs radio-mesh).
- **Charging: universal Qi primary + bundled ultracompact USB-C→pogo
  adapter.** Two paths, both common:
    1. *Primary — universal Qi (WPC).* Any random pad works: iPhone
       MagSafe, Android Qi, hotel nightstand, café dock, friend's
       charger. No proprietary inductive puck — Apple-Watch-style
       chargers are explicitly rejected (loseable, uncommon, hostile
       UX for a membership-grade device).
    2. *Bundled accessory — ultracompact USB-C → pogo adapter.* Tiny
       first-party clip (think keyring-sized) that takes any USB-C
       cable on one end and lands magnetic pogo pins on the wallet's
       back pads on the other. Lets a member top up from any laptop /
       phone charger / power bank without needing a wireless pad. The
       same pads double as the factory-recovery contact (single
       hardware surface, two roles).
  Members never need to carry a wallet-specific cable — they bring
  their existing USB-C cable + the matchbook-sized adapter, or just
  drop the wallet on any wireless pad.
- **Brand:** ships under **cocottetech** (Cocotte public umbrella —
  see brand-family memory). Not Demimonde-branded, not co-branded
  with Sansonnet.

### Peer pairing + direction (calculator-to-calculator)

The core interaction: two members want to move crypto. How do their wallets
find each other, and how does each side know *who's sending* vs *who's
receiving*?

**Pair (proximity, ~seconds):**
```
   [A] ─── tap backs together ─── [B]
        NFC handshake (UID exchange)
              │
              ▼
        BLE / radio-mesh secure channel opens
        ephemeral session key derived
```
NFC is the *introduction* (intentional, physical, can't happen by
accident in a crowd). BLE / the radio mesh carries the actual session —
NFC's range is too short to hold the channel through the rest of the UX.

**Declare direction (hardware toggle — three positions):**

A physical slide / rocker switch on the edge of the card with three
detents. The switch position *is* the wallet's mode — there's no
software state to be spoofed, and a glance tells you what the device
will do next.

```
     ┌──────────────────────────────────────┐
     │  ◀── [ LOCK | SEND | RECV ] ──▶      │
     │         ▲      ▲      ▲              │
     │         │      │      └─ accepts incoming transfer
     │         │      └──────── will push out a transfer
     │         └─────────────── default; radio + screen idle, no tx
     └──────────────────────────────────────┘
```

- **LOCK** — default resting state. Radio off (or beacon-only), display
  shows balance, no transfer can occur. You carry it like this.
- **SEND** — wallet is armed to push. Amount entered on the keypad is
  treated as outgoing. Press `=` to commit (after peer pair + short-code
  match).
- **RECV** — wallet is armed to pull / accept. Will only accept an
  incoming transfer matching the amount shown.

**Light language (active-state visualization):**

When the wallet is active, two independent light surfaces communicate state:

1. **Toggle pulse** — a soft, slow pulse directly under the slide switch.
   Always present while the wallet is awake. Colour matches the switch
   position. This is the "what mode am I in" indicator — readable in a
   pocket-glance.
2. **Full perimeter LED strip** — a thin RGB strip ringing the edge of
   the card. Used for handshake / transfer state: scans toward the peer
   on pair, fills as confirmation progresses, flashes on commit, dims
   to the toggle colour at idle.

Both surfaces share the same colour grammar:

```
   LOCK   →  white      ── soft idle pulse, no radio activity
   SEND   →  red        ── armed to push; ramps when amount is entered
   RECV   →  green      ── armed to accept; ramps when amount is shown
   PAIR   →  amber sweep around perimeter, both ends → meeting point
   MATCH  →  short-code-coloured sparkle (deterministic from session key)
   COMMIT →  full-strip flash in the sender's red / receiver's green
   FAIL   →  perimeter blinks red 3x, toggle returns to white
```

The toggle pulse is **independent** of the perimeter strip — if the
perimeter is doing a handshake animation, the toggle keeps pulsing its
mode colour underneath, so the member can always see *what their own
device thinks it's doing* even mid-transfer.

ASCII intent:

```
   ┌─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─┐    ← perimeter RGB strip
   ◉                            ◉   (handshake / transfer state)
   ◉   display + keypad         ◉
   ◉                            ◉
   ◉   [ LOCK · SEND · RECV ]   ◉   ← slide switch, with its OWN
   ◉      ░░░░░ (pulse)         ◉      soft-pulse light under the
   ◉                            ◉      current detent
   └─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─◉─┘
```

For a transfer to happen, **one wallet must be on SEND and the other on
RECV** — same position on both = no-op. This makes direction physical,
mutual, and impossible to fat-finger: if both members aren't actively
agreeing on roles, nothing moves.

Both sides must still press `=` within ~10s, and both screens show a
matching short code (4-digit, derived from the session key); mismatch
aborts. Returning the switch to LOCK at any point kills the session.

**Why not "scan a QR"?** QR works but it requires one side to be the
"merchant" and the other the "customer" — asymmetric, terminal-ish, and
needs a camera. Tap-to-pair keeps both wallets peers: either side can
start, both confirm, no roles.

### Open questions
- SIM/radio provider strategy (MVNO vs. satellite IoT vs. LoRa-style mesh)?
- Relationship to existing standards (Ledger/Trezor seed compat? FIDO2?
  custom?).
- **Session channel *after* the NFC introduction — this is the single
  biggest unresolved hardware decision.** Pairing transport itself is
  decided (NFC). The session that follows could be:
    - **BLE** — natural for nearby peers, off-the-shelf chipsets, also
      gives find-my-wallet a free local proximity stage. Costs an extra
      antenna + radio + paired-phone UX wrinkle. Does *not* work if
      the two members are not physically close (e.g. wallet-to-wallet
      remote tipping).
    - **In-band cellular, platform-relayed.** Both wallets push the
      session through the cocotte platform over their own LTE-M
      radios. Works at any distance. Costs platform availability for
      every transaction and adds latency (sub-second still, but not
      instant). Simpler BOM — no BLE radio at all. Find-my-wallet
      loses the BLE proximity stage.
    - **Custom sub-GHz peer mesh (LoRa-class).** No platform in the
      loop, works peer-to-peer at range, but adds another radio +
      antenna + cert burden.
  Decision blocks BOM (BLE chipset yes/no) and find-my-wallet design.
- **Pogo-pad layout + adapter form factor.** Charging is decided
  (Qi primary + bundled USB-C→pogo adapter using the same back-pad
  contacts that also serve factory recovery). The contact area is a
  **perfectly smooth, shallow indent** milled into the card's back
  face — the pads sit flush at the bottom of the indent, magnets ring
  it, and the adapter clicks in self-aligning. No raised hardware on
  the card surface (snags in a pocket, ruins the calculator illusion).
  Remaining design work:
    - Indent depth + diameter — deep enough for positive tactile
      registration with the adapter, shallow enough not to weaken
      the card or interfere with the NFC patch and recovery QR
      window on the same back face.
    - Number / pitch / position of the pogo pads inside the indent
      (must survive pocket wear, accept magnetic alignment).
    - Adapter form factor — keyring fob, flat tab, magnetic disk?
      Must be small enough that members actually carry it and
      cheap enough to replace if lost.
    - Whether the same pads carry data (firmware OTA fallback,
      bricked-device recovery) or are power-only with all data
      going over the radio.

### Feasibility (web research, 2026-05-18)

Quick scan of what already ships vs. what's still hard. Component-by-component
verdict on whether the concept is buildable in 2026 with off-the-shelf parts.

**Card-form factor with display + secure element — SOLVED.**
- Tangem ships a card-thin NFC wallet at EAL6+ secure element (no display,
  no battery, no radio). Arculus the same.
- Ledger Stax ships an e-ink + wireless-charging crypto wallet at credit-card
  *footprint* (~3 mm class, not card-thin) with curved e-ink, EAL6+ secure
  element, designed by Tony Fadell. Direct proof that e-ink + Qi + crypto
  works in this size class.
- ERA Wallet (open-source) puts e-ink + touch in a 5.5 mm card.
- Muxcard (experimental) puts e-ink + NFC + microcomputer in a **1 mm**
  card — proves the upper bound. Sources:
    - https://blackseedink.com/blogs/news/tangem-wallet-review-2026-nfc-crypto-hardware-wallet
    - https://knowingbitcoin.com/ledger-flex-review-2026-touchscreen-hardware-wallet/
    - https://cada.news/ledger-stax-review/
    - https://github.com/ERAWLT

**Skepticism worth naming.** Stacker News post "Don't bother with hardware
wallets in card format" — the Bitcoin-maximalist hardware-wallet community
already pushes back on card wallets (durability, single-point-of-failure,
no air-gap). The cocottetech wallet is positioned as a **retrieval +
peer-transfer** surface, not deep cold storage, which deflects most of
that critique — but worth being explicit about the framing.
    - https://stacker.news/items/84506

**eSIM + LTE-M radio — SOLVED at module level.**
- Kigen MFF4 eSIM is **2 mm × 2 mm** (production-grade). Standard MFF2 is
  5×6 mm. Plenty thin enough for a 3 mm card.
- iSIM (eUICC integrated into the cellular SoC) is emerging — eliminates a
  whole component for a custom design.
- "Any SIM purchased in 2026 must support LTE-M, NB-IoT, or 4G LTE at
  minimum" — LTE-M is a default, not a special order. Sources:
    - https://kigen.com/resources/blog/the-future-of-esim-hardware/
    - https://spenza.com/esim/iot-sim-cards-guide/

**Qi wireless charging at card thickness — FEASIBLE but the edge case.**
- Standard Qi struggles with a 2 mm plastic gap (some chargers won't even
  start). Qi **v2.1** explicitly supports 2 mm air gap + magnetic
  alignment — this is the standard to target, not v1.x.
- The coil must be tuned to the card's exact stackup. Off-the-shelf
  card-format Qi coils exist but their performance on arbitrary third-party
  pads is non-uniform. Risk: a member's iPhone MagSafe pad charges it
  fine, the hotel pad doesn't. Source:
    - https://graniteriverlabs.com/en-us/technical-blog/beyond-qi2-wireless-charging

**Power budget — solvable with a 3-tier hybrid stack.**

The actual hard problem isn't bulk energy, it's the **peak-current
mismatch**: a card-thin Li-Po can hold a few hundred mWh but can't
deliver the 1–3 A spikes that LTE-M / NB-IoT transmit bursts demand
for 1–2 seconds. The IoT industry already solved this for smart meters
and cellular trackers; the same architecture maps directly onto a
membership wallet:

1. **Bulk energy — ultra-thin Li-Po pouch.** Mass-produced down to
   0.4–1.0 mm. A 1.5–2.0 mm card-style cell delivers ~100–160 mAh at
   3.7 V (Serui, PADRE, Grepow, UFine, Samsung/LG plastic-pouch parts).
   Honeywell already ships products with 0.8 mm cells. Chinese supply
   chain is mature here.
2. **Pulse buffer — supercapacitor (or Li-SOCl₂ + supercap hybrid).**
   Absorbs the 1–3 A LTE-M transmit burst the Li-Po alone can't
   deliver. A 220 F hybrid supercap part delivers ~15 A peak. During
   sleep the Li-Po trickle-recharges the cap. This is the *de facto*
   architecture for cellular IoT in 2026.
3. **Aspirational always-on trickle — betavoltaic ("diamond")
   battery.** Betavolt's Ni-63 / diamond unit is **15 × 15 × 5 mm**
   today at 100 µW; a 1 W version is announced. Microwatts are
   nowhere near LTE-M's needs **directly**, but the betavoltaic's
   role is *trickle-recharging the supercap and Li-Po while the
   wallet sits in a drawer*. 50-year half-life on the isotope ≈ a
   wallet that doesn't go flat if a member loses it in a couch for a
   year. Real status: still pre-mass-market, regulatory questions on
   consumer radionuclides — treat as **v2 ambition, not v1 BOM**.

Sources:
- https://www.serui-battery.com/News/xingyezixun/ultra-thin-1-5-2-0mm-3-7v-100mah-card-style-lithium-polymer-batteries.html
- https://www.pdbattery.com/ultra-thin-battery.html
- https://www.grepow.com/blog/ultra-thin-lithium-polymer-battery-for-thinnest-application.html
- https://www.digikey.com/en/articles/use-hybrids-to-bring-the-benefits-of-both-batteries-and-supercapacitors-to-power-iot-designs
- https://hackaday.com/2026/04/28/2026-green-powered-challenge-supercapacitor-enables-high-power-iot/
- https://newatlas.com/energy/betavolt-diamond-nuclear-battery/
- https://www.world-nuclear-news.org/articles/nuclear-battery-chinese-firm-aiming-for-mass-mark

Duty-cycle posture remains required regardless of stack:
- Radio idle in LOCK (beacon-only or fully off).
- Radio wakes only on toggle change, NFC tap, or scheduled push.
- E-ink display retention is free (no draw while showing balance).

**Overall feasibility verdict — buildable with 2026 parts.**
- No single component requires invention. Every piece ships somewhere.
- The integration challenge is real: cellular + Qi v2.1 coil + e-ink +
  EAL6+ secure element + battery + perimeter LED + hardware switch, all
  in a ≤3–4 mm card, with reasonable yield. This is a hard
  industrial-design problem, not a research problem.
- Realistic path is **partner with an existing card-wallet ODM** (the
  same supply chain that builds Tangem / Arculus / Ledger Stax) rather
  than greenfield. ODM relationship + custom firmware + cocottetech
  brand layer is the shape of the project.

### Find-my-wallet

The cellular radio that exists for transfers doubles as a built-in
**self-locator** — fundamentally better than AirTag / Tile (which rely
on a crowd-sourced mesh of other people's phones). The wallet phones
home on its own.

**The trigger is the *platform*, not the phone.** Member says "find my
wallet" from the cocotte app, web view, or even SMS to the platform.
The platform pushes an **OTA command** to the wallet over LTE-M —
exactly the same downlink path used for any other platform-initiated
message. The wallet doesn't have to be near the member's phone, BLE,
or wifi to receive the find request. Critically: this means **a member
who has lost both their wallet *and* their phone can still find the
wallet** — they log in on a friend's device or call the platform.

Three response stages, escalating with how close the member is:

1. **Global — cellular self-report (LTE-M / NB-IoT).** On receipt of
   the platform OTA find command, the wallet immediately wakes the
   modem, posts the nearest cell tower IDs + signal strength back to
   the platform, and the member sees a city-level pin in the app /
   web. Wallets also self-report on a slow background schedule (e.g.
   1×/hour while in LOCK) so the *last known location* is always
   warm — useful when cellular happens to drop at the moment the
   member panics. Power impact is bounded by the duty-cycle posture
   already designed in (modem otherwise idle).
2. **Local (~10–100 m) — *only if BLE is already on the BOM*.** This
   stage is **conditional**, not a given. BLE was originally proposed
   as the post-NFC session channel for peer transfers (see the
   transfer-session-channel open question). If that decision lands
   on BLE, then find-mode gets a free hot/cold proximity stage — the
   platform's OTA command flips the wallet into a higher-rate beacon
   and a member's phone shows a range bar. **If transfers end up
   running over cellular (relayed through the platform) instead of
   BLE, this whole stage disappears** and we go directly from stage
   1 (city-block cellular pin) to stage 3 (strobe + beep). The
   wallet is loud and bright enough on platform command that the
   missing middle stage is acceptable — you walk into the apartment
   and follow your ears.
3. **In-hand (~cm) — perimeter LED strobe + loud piezo tone.** Same
   OTA escalation. The wallet drives the **full perimeter LED strip**
   in a high-contrast strobe (reusing the transfer-state hardware —
   see the Light language section) and fires a **simple loud tone
   generator** — sub-1 mm piezo bender driving a single fixed audible
   frequency (~3–4 kHz, the ear's peak sensitivity). Not a speaker,
   not a musical synth, not voice prompts: one tone, intermittent,
   loud enough to find the wallet under a couch cushion or inside a
   bag. The simplicity is the point — no codec, no DAC, single GPIO
   driving the piezo through a step-up, sub-mA at the cap-buffered
   peak.

Escalation is **member-controlled from the platform UI**, not
automatic by RSSI — "show me on a map", "make it beep", "make it
beep and flash" are three buttons that send three different OTA
levels. The wallet has no idea how close the member's phone is; it
just does what the platform last told it to do.

**The 30-year-old wallet argument for BLE.**

Re-examining the BLE question on **longevity / degradation** grounds:
imagine the wallet is 30 years old. The piezo bender has died (glue
fatigue, mechanical wear, solder joint failure). The perimeter LED
strip has dimmed past usefulness (phosphor degradation, driver IC
end-of-life). The e-ink display ghosts. Battery is shot — but the
betavoltaic trickle (v2) keeps the radios alive.

In that future, **only the solid-state radios are reliably alive**:
the cellular modem and (if equipped) BLE. The find sequence
degrades as follows:

| Stage | Hardware needed | 30-yr survival |
|---|---|---|
| 1. Cellular pin | LTE-M modem + antenna | ✓ likely OK |
| 2. BLE proximity | BLE chipset + antenna | ✓ likely OK |
| 3a. Strobe | LED strip + drivers + power | ✗ failure-prone |
| 3b. Piezo tone | piezo bender + step-up | ✗ failure-prone |

Without BLE, a 30-year-old wallet with dead transducers gives you a
city-block pin and nothing else — you can't narrow from "in this
house" to "in this drawer". **With BLE, even with all output
hardware dead, the searcher's phone becomes the UI** (sound,
vibration, visual hot/cold meter all run on the phone side). The
wallet just has to emit a silent beacon — which is the same thing a
$5 Tile does, with no transducers at all.

This reframes the BLE BOM question: BLE is justified **not only by
the transfer-session-channel decision, but independently by
**longevity guarantee****. A wallet that's a membership-grade
artefact (potentially handed down, kept for decades) needs at least
two redundant find paths, and the two that age best are both
radios.

Verdict shift: **lean toward BLE on the BOM** regardless of the
transfer-session-channel outcome. Even if transfers run
platform-relayed over cellular, BLE earns its place as the
last-mile finder when local output transducers are end-of-life.

**State + privacy:**
- Find-mode is an **out-of-band command**, not a switch position. The
  hardware toggle stays where the member left it (LOCK / SEND / RECV);
  find is just an additional behaviour layered on top by the radio
  firmware.
- The wallet's location reports are visible **only to the member's
  authenticated account** on the platform. The platform never shares
  wallet pings with third parties — and per the [[stance]] section,
  not with any regulatory or law-enforcement query either.
- A member can **disable cellular self-reporting** in the app (the
  wallet then only locates via BLE while the member is within range,
  like a dumb Tile). Default is on; member-controlled.
- "Anti-stalker" inversion is a non-problem here: unlike AirTag, this
  wallet can't be slipped into someone else's bag to track them — it's
  bound to a member account at provisioning and only reports to that
  account's owner.

### Prior art — is anyone already doing this? (2026-05-18)

**Short answer:** every *ingredient* ships somewhere; **the exact
combination does not**. The defining mix — standalone cellular radio +
calculator-keypad UI + peer-to-peer crypto transfers between same-brand
wallets + bundled as a membership benefit — is unclaimed in the market
as of May 2026.

Ingredient-by-ingredient prior art:

- **Card-form NFC wallet (Tangem, Arculus, Cryptnox, Ellipal X,
  Satochip, Keycard, CoolWallet, BitLox).** Mature category. All EAL6+
  secure-element cards. None have their own radio — they all piggyback
  on a host phone's NFC. Some (Tangem) support card-to-card key transfer
  over E2EE NFC, but that's for *backup*, not for sending value between
  two members.
    - https://tangem.com/en/
    - https://cryptnox.com/
    - https://keycard.tech/
    - https://www.ellipal.com/products/ellipal-x-card

- **Hardware wallet with built-in cellular — does NOT exist as a
  standalone product.** Vaulttel ships a wallet that fits *into a
  phone's SIM tray* — opposite shape: it uses the *phone's* radio, not
  its own. There are research proposals ("SIM as hardware wallet" EIP,
  Nadcab Labs) but no shipping card-form wallet with its own cellular
  modem. This is the **clearest greenfield slot** in the design.
    - https://coingeek.com/new-hardware-wallet-can-store-crypto-in-your-phones-sim-card-slot/
    - https://news.bitcoin.com/this-new-hardware-wallet-fits-into-a-smartphone-sim-tray/

- **Peer-to-peer offline transfer between wallets.** COLDCARD Q has
  "Key Teleport" (NFC/QR for moving sensitive data between two COLDCARD
  Q units). Tangem cards talk card-to-card for key backup. Neither
  frames the interaction as **"two members punch in amounts and send
  crypto to each other in seconds"** — both are still
  vault-operator-to-vault-operator workflows. The calculator-style
  consumer P2P framing is unclaimed.
    - https://coldcard.com/
    - https://www.researchgate.net/publication/337935793_NFC_Pure_Wallet_PW_An_Offline_and_Real-time_Blockchain_transaction_Architecture

- **Keypad on a crypto device.** SecuX W20 and BitLox Ultimate have
  keypads, but only for PIN entry, not as the primary transaction UI.
  Calculator metaphor (amount-on-keypad, `=` to send) is **not used by
  anyone shipping**.
    - https://www.amazon.com/SecuX-W20-Crypto-Asset-Hardware-Wallet/dp/B07Q19WN6G

- **Membership-bundled hardware.** NFT-as-membership exists, and
  Ledger sells limited-edition bundles (Monopoly x Ledger Flex), but
  no consumer brand bundles a hardware wallet **as a tier benefit**
  the way cocottetech proposes. The closest analogues are AmEx
  Centurion's physical metal card or Brilliant Earth's club
  hardware — neither is a wallet.

**Conclusion.** The wallet sits at the intersection of four mature
categories (card NFC wallets, cellular IoT, P2P offline payment
research, membership-as-product) where **no one has put all four
together**. The radio + calculator-UI + same-product P2P combination
is the actual novel claim. Card-form crypto-wallet is the well-worn
substrate everyone else competes on; the differentiation is *what
the radio enables* (instant transfers, push notifications, no-phone
dependency).

### Stance

- **Regulatory posture: explicitly not a design constraint.** The
  member's work already lives in gray-area space and has been
  unjustly punished by regulatory systems. This product is built
  on a liberty-first / sovereignty-of-the-member axiom; compliance
  questions are downstream operational concerns, not gating design
  inputs. Documented so future contributors don't smuggle the
  inverted priority back in.

### Related
- brand-family memory — ships under cocottetech (Cocotte public umbrella).
- Membership tier definitions — "standard" tier needs to be defined before
  this idea is committed.