Hardware-Based Point-of-Sale Architecture
PaidX couples low-cost physical microcontrollers (ESP32) with high-throughput L2 settlement on Base. This specification documents the communication boundaries, state transitions, and cryptographic verification policies.
System Overview
Physical retail checkout demands predictable latency, intuitive amount entry, and instant customer feedback. Traditional mobile crypto payments often force merchants to carry personal phones running mobile wallet apps, exposing private keys to counter staff and risking misdirected funds.
PaidX enforces a strict separation of concerns across three distinct entities:
User Presentation Only
Gathers numeric amount, presents dynamic QR code, and reports final settlement.
Quote & State Bridge
Generates unique request nonces, listens to Base RPC events, and formats receipts.
Settlement Truth
Processes transfer transactions, emits transfer events, and delivers immutable receipts.
Touchscreen & Firmware Flow
The terminal firmware is built around the ESP32 (38-pin development board without external PSRAM). Due to the limited 320 KB internal SRAM, strict memory discipline is enforced:
- Zero delay() statements: All pacing, timeouts, and animation cycles use non-blocking
millis()comparisons inside the master loop. - No dynamic String allocation: Fixed-width character buffers with bounded
snprintfavoid progressive heap fragmentation on 24/7 retail hardware. - The Phase Mutex: SoftAP captive portal mode peaks near 75 KB heap usage, while TLS client mode requires 107 KB. To prevent out-of-memory panics, an ordered 5-step teardown completely frees SoftAP buffers before any TLS handshake begins.
- Touch Calibration: Four-point resistive calibration coordinates are persisted to SPIFFS flash memory, surviving power loss and hardware reboots.
Payment Request Lifecycle
The terminal transitions through an explicit finite state machine:
PENDING state, the terminal maintains a 180-second TTL. If no confirmed transaction is registered on Base within the window, the payment request expires, the QR pattern clears, and the terminal reverts to IDLE.Base Transaction Verification Mechanics
Because customers initiate transactions from arbitrary mobile wallets, the relay service independently validates the following criteria on Base before approving settlement:
Verifies that the transaction was executed on Base Mainnet (8453) or Base Sepolia (84532). Transactions on alternative EVM chains are rejected.
Matches the destination address against the merchant's configured settlement vault.
For native ETH, validates the transferred value in Wei against the quoted rate. For ERC-20 payments (such as USDC on Base), validates the token contract address, verifies the Transfer(address,address,uint256) log event, and checks exact decimal scaling.
Requires verified inclusion in a confirmed Base L2 block. Never reports success based on mempool visibility or frontend assertions.
Receipts & Explorer Integration
Upon verified settlement, the terminal emits a receipt record linking directly to the public blockchain explorer:
- Base Mainnet Explorer:
https://basescan.org/tx/[tx_hash] - Base Sepolia Explorer:
https://sepolia.basescan.org/tx/[tx_hash]
The terminal displays the transaction summary, confirmation count, and an optional QR code allowing the customer to inspect the verified BaseScan record directly on their device.
Security & Cryptographic Key Separation
Merchant funds flow directly from customer wallets to the merchant's designated cold storage or multi-signature smart vault on Base.
Development & Compilation
The firmware compiles cleanly via the Arduino CLI with the official Espressif ESP32 core (v3.3.12):