Twitxy Saved

blackbox

Verified account This account is verified. Learn more

@blackbox_pos

Bridging the future of payments
blackboxpos.com Joined October 2025
0 Following 64 Followers 15 Posts

Latest posts 5

blackbox Verified account @blackbox_pos
Blackbox Devlog #10: prepaid card and tap-to-pay support added

Prepaid card support:

- A tap reads the card’s balance and counter, checks whether the sale is allowed, writes the new balance back, and signs the result; no server, no live transaction
- The terminal holds a debit key that can spend down a card but cannot create value; issuing and loading stay in the Vault, which holds the on-chain reserve behind each card
- Settlement is a separate, later act: the terminal journals every completed tap and batches them to the Vault when it can; until then it runs on an unsettled cap, bounding the worst case of a terminal that never phones home
- Currently a demo tier running on cheap NTAG cards with a custom MAC rather than the DESFire EV3 secure element the shipping card will use; disabled by default behind a compile-time flag

Handling failed taps:

- Every debit is written to a journal as an intent before the card is touched, removed only once the card write is confirmed; a card pulled mid-write, a power loss, a reader glitch each land in a state the terminal can name and recover from
- A write known not to have landed charges nothing; a write whose outcome is unknown parks until the same card is tapped again, resolving to exactly one charge or none
- Cards were yanked mid-write deliberately five times at the bench; the ledger came out with five charges, no doubles, no losses
- A sale cancelled at the instant of card write raises a flag the cashier must acknowledge, and the same card is refused a second tap until they do; the guard is held until cleared, not on a timer

Vouchers and staff keys:

- Item vouchers put a product rather than a balance on a tag, each backed by a chain cell that closes automatically once settlement lands
- Staff keys use the cryptographic originality signature NXP puts on genuine NTAG silicon; a price override requires a staff tag. The demo cards turned out to be counterfeit and cannot produce this signature, which is precisely why staff authorisation uses it

Bug: UI freeze under concurrent flash writes:

- The confirmation screen began freezing hard after a successful card debit followed immediately by a settlement sync
- Cause: an SPI flash write on the ESP32-S3 briefly stalls the other CPU core; the journal task was unpinned, so it ran on the core opposite the UI, dropping the UI’s clock tick mid-sleep
- Fix: pin flash-writing tasks to the same core as the UI, so the stall lands on the networking core; seventeen hours of uptime and a full bench run with no recurrence. The same latent bug was found and fixed in the Bitcoin header path before it surfaced

Also:

Add Item form now has a Scan barcode button that arms the scanner in place and drops the code into the field, keeping name and price already typed
Space bar on the Add Item keyboard was hidden under the footer bar; fixed

Next: watchdog for a genuinely wedged terminal, certificate pinning so settlement cannot be spoofed on a hostile network, on-device voucher and staff key support, and the DESFire secure-element card once stock arrives.

Full devlog: blackbox.wyltekindustries.com
0 replies 8 reposts 15 likes 277 views View on X
blackbox Verified account @blackbox_pos
Blackbox Devlog #9: Bitcoin support added! Plus, a purpose-built PCB

Three developments this fortnight at three different distances from a shipping product: the new board is running, #Bitcoin is in as a new payment rail, and for the first time Blackbox has a custom-designed circuit board.

Bitcoin payment support:

- Receive-only, with no private key on the device; the merchant scans their Bitcoin wallet's public key and each sale derives a fresh receive address
- Two distinct settlement states: SEEN means unconfirmed on the network; VERIFIED means the terminal has validated a cryptographic proof against block headers it audited itself, from a firmware checkpoint upward through proof of work and consensus rules. A connected server can help locate a payment; it cannot fabricate one
- Sixteen test suites run against real mainnet and signet vectors
- Disabled by default; running on signet until the hardware checkpoint passes

First purpose-built PCB:

- A circuit board designed around Blackbox's own requirements rather than repurposed from a development board
- ESP32-S3, 5-inch 800x480 display, 4 layers, single 3.3V rail, printer, scanner, NFC, and microSD; 193 footprints, 125 nets, ERC clean and routed
- Design generated from a source model: schematic, PCB, BOM, placement file, pinout doc, and firmware pin header all produced from two Python files, with automated checks re-validating pin assignments on every build
- Errors caught before copper include a level translator wrong on all five signals, a shorted eFuse footprint, a printer inrush of 200A resolved with a Miller capacitor ramping it to 1.4A over 6.6ms, and over-voltage protection set to the printer's 9V limit
- Not yet sent for fabrication; six blockers remain

The new board is running:

- The VIEWE S3 boots, renders, takes touch, and talks to the testnet indexer
- First real action: resolved a merchant address to its funding block, verified against a prediction rather than accepted at face value
- Printer confirmed working via its own self-test print before any firmware interaction
- Scanner driver reworked: a non-responsive handshake no longer marks the scanner absent; the driver falls back to listen-only mode and reads decoded barcodes as plain text

Light client sync start:

- A light client needs to know where on the blockchain to begin; too low wastes hours, too high silently misses incoming funds while reporting healthy
- Start height now has explicit provenance: pulled from the provisioning bundle if present, otherwise a one-time setup screen offers a live indexer lookup or manual entry
- Manual entry validated asymmetrically: above the chain tip is refused, just under it warns; a failed lookup sets nothing rather than defaulting to zero

Next: re-run light client bootstrap checks through a real scanner, complete the Phase 1 hardware checkpoint, take the first Bitcoin payment on the device over signet, and measure a panel for the PCB.

Full devlog: blackbox.wyltekindustries.com
1 replies 9 reposts 22 likes 6.2K views View on X
blackbox Verified account @blackbox_pos
Blackbox Devlog #8

v0.3.0 is complete and the prototype hardware cycle is closed. Development now moves to a new board, more capable hardware, and a fresh codebase tree. v1.0.0 begins here, and is the basis of the intended commercial pilot.

v0.3.0 ships:

▪️Tier-1 transport, live pricing, on-chain confirmation, and over-the-air updates are now a stable release
▪️Delivered to an existing unit with no cable or manual intervention: the updater disguised itself as a routine firmware file the old software was already expecting, downloaded silently, repartitioned the device storage in place, and brought the unit up on v0.3.0
▪️The prototype codebase is now frozen, complete for the hardware it was written for

v1.0.0 begins, new hardware:

▪️v0.3.0 hit a hard storage limit: adding the on-device light client, which lets BlackBox watch the blockchain directly without a separate server, would have exceeded available flash memory with no room to spare
▪️v1.0.0 moves to a new board with significantly more headroom: 16 MB of flash (vs 4 MB), more RAM, a larger capacitive touchscreen, and a faster processor
▪️The new build occupies 25% of available storage, enough room to add the light client and more
▪️No major codebase rewrite was needed: most of the light client code turned out to be standard C that the project already compiles, with no framework-specific dependencies to untangle
▪️Enclosure design work is underway alongside the new hardware

Hardware bring-up:

▪️USB connection, display controller, and touchscreen driver all required correction from what the vendor documented, each identified and fixed before powering on
▪️A scanner bug fixed: the device was reopening the connection at high speed without confirming the scanner had acknowledged; after a restart the scanner would appear connected but be completely unresponsive, with nothing in the logs
▪️Headers soldered, custom cables made up for the printer, scanner, and NFC module; all GPIO pins accounted for in a single reference file, making the eventual next board port a one-file change
▪️Continuous integration: automated build and test pipeline set up for the first time, catching eight issues in a pre-hardware review before anything was powered on.

Next: powering on the new board for the first time and verifying display, touch, printer, and scanner. Then getting the light client running on-device.

Full devlog: blackbox.wyltekindustries.com
3 replies 13 reposts 41 likes 2.7K views View on X
blackbox Verified account @blackbox_pos
Blackbox Devlog #7

The device lost its last server dependency, got live pricing back, and gained over-the-air firmware updates. Blackbox is now ready to migrate to new hardware.

Server dependency removed

▪️Two-tier transport complete: device pairs with the merchant's phone by QR, resolves over mDNS, and routes everything through it — signing via a local TLS relay, chain reads and balance via a proxy on the phone
▪️No separate relay, indexer, or server required
Six device-only bugs fixed at the live hardware checkpoint
▪️Board's 4 MB PSRAM enabled; receipts gained the Blackbox logo and a printed refund receipt

Pricing

▪️Live pricing restored — background task feeds from Binance's CKB ticker crossed with a daily USD→fiat table, CoinGecko fallback with exponential backoff
▪️Six display currencies; quotes lock rate at strike; stale feed blocks new quotes; tapping checkout triggers an immediate refetch
▪️Quantization bug fixed: payment QR was rounding CKB to two decimals while the chain watcher required full precision — at any real rate, roughly half of paid sales would have gone unconfirmed. One quantization at quote-strike keeps QR, watcher, and receipt in exact agreement

OTA updates

▪️v0.3.0 ships with a permanent factory updater partition — tap Update in Settings, device reboots into a 1 MB updater, browser on the LAN uploads new firmware and assets; bootloader falls back to the updater on a bad upload
▪️Existing v0.2.6 units migrate with no cable via web-OTA, which repartitions flash in place
▪️our brick vectors caught in review before hardware, including a cross-core cache race during a table write

Next: OTA and migration hardware checkpoint, then the Fiber instant-settlement path. Blackbox is ready to migrate to the new board, new components, and eventually new housing.

Full devlog: blackbox.wyltekindustries.com
1 replies 12 reposts 31 likes 2.5K views View on X
blackbox Verified account @blackbox_pos
Blackbox Devlog #6

The headline this fortnight: the payment confirmation placeholder is gone. BlackBox now confirms sales against the chain itself — the device detects incoming settlement and advances to success automatically.

Peripherals:

▪️GM861S barcode scanner live on UART2: scan a product, it looks up inventory and drops straight into the cart
▪️QR204 thermal printer live on UART1: prints a real receipt — line items, totals, payment URI, live timestamp from a new clock_svc
▪️Several hardware-only bugs found and fixed: inverted QR/barcode rendering, a per-frame memory allocation causing intermittent QR failures, a Wi-Fi build misconfiguration costing 614 KB, and a payment URI scheme correction

On-chain confirmation:

▪️Three new components: ckb_addr decodes bech32m addresses to lock scripts on-device, chain_svc speaks JSON-RPC to a CKB indexer node, and confirm_svc runs a FreeRTOS poll task that arms on QR display and auto-advances to success when the merchant lock's capacity rises by the sale amount
▪️Concurrency bugs caught in review: a dual-task race that could produce a false CONFIRMED on a money path, fixed with a generation counter and a critical section closing a TOCTOU between generation check and state write
▪️Confirmed transaction hash now captured at CONFIRMED and shown on the success screen and receipt
▪️Chain infrastructure stood up to support this — full details in the devlog below

Keyless merchant wallet:

▪️A shop-floor device should never hold a key — refunds and sweeping takings are handled via the Agent Gateway in the Vault companion wallet
▪️The POS holds only a scoped biscuit token, provisioned by scanning a QR bundle from the wallet, and submits spend intents over TLS — the phone re-validates against policy and signs
▪️Refund flow and result screen added; async takings balance and a Sweep screen for moving CKB to a cold-storage address
▪️Several issues caught in review before reaching hardware: corrupt-token parsing, a wrong-payee hazard from a stale scanned recipient, a send-path mux gap, and a provisioning bundle silently truncated by a 200-byte scan buffer (biscuit bundles run 700–1000 chars)
▪️Build sits at 61% flash / 34% RAM

Full devlog: blackbox.wyltekindustries.com