The Trustless Receipt Flow

The end-to-end lifecycle of a single unlock is as follows.

1. Discovery. User opens the burn portal, connects a wallet, and reads the device's published deviceId (keccak256("ESP32-" || hardware_id)) from a label, BLE advertisement, or QR code.
2. Burn. User approves and burns TATSU against (featureId, deviceId). The contract debits the supply, increments the nonce, and emits FeatureUnlocked.
3. Observation. The cloud's chain listener receives the event. It confirms the event reached the configured number of confirmations, then composes a canonical receipt and signs it with the operator's signing key.
4. Persistence. The signed receipt is written to feature_unlocks and made available via /api/receipt.
5. Delivery. The portal — still in the user's browser — fetches the signed receipt and writes it to the device's BLE ReceiptCharacteristic.
6. Verification. The firmware reconstructs the canonical preimage from the receipt fields, verifies the ECDSA signature against the public key compiled into its own image, checks the nonce against its local registry to prevent replay, and on success, persists the unlock and enables the feature.

The critical property is that every step from (3) onward could be performed by an adversary, and the system would still be safe. The only thing that matters cryptographically is that the receipt was signed by the holder of the private key matching the device's hardcoded public key. Everything else is plumbing.