Metal Bare

METAL — Research Brief & Technical Overview

Designing a low-cost, offline-capable contactless payment transmitter for small businesses in my country. This document provides a deep technical narrative, implementation notes, and an evaluative roadmap.

Executive Summary

METAL is a purpose-built payment transmitter that enables secure, contactless transfers using the national instant payment rail (NIP) while minimizing merchant costs and eliminating dependence on customer-side internet or payment cards. It pairs a lightweight RISC-V embedded system with a deterministic transmission protocol ("Jinx"), Rust firmware, and a cloud backend to provide an end-to-end payment experience tailored for micro and small businesses.

Motivation & Context

Small businesses — like our parents' supermarket in Lagos — pay disproportionate fees and face unreliable connectivity. Traditional POS solutions either rely on expensive hardware or card networks (Mastercard/Visa) with high interchange costs. In contrast, mobile transfers powered by NIP offer a low-fee, nation-wide settlement mechanism. METAL leverages this to keep costs low while providing the convenience of contactless payments without physical cards or Apple-restricted NFC paths.

Design Goals

  • Cost-effective hardware for mass adoption.
  • Offline-first operation: payments must work when customer devices have no internet.
  • Security: strong authentication and end-to-end encryption without large compute overheads.
  • Extensibility: a platform that can integrate with banks, dashboards, and alternative connectivity (SIM, Wi‑Fi, satellite).

System Architecture (high-level)

METAL is composed of three logical layers:

  1. Edge device — RISC‑V microcontroller running Rust firmware and FreeRTOS tasks (Keypad, LCD, Jinx, Pipe Stream).
  2. SDK / Mobile — Integrated into bank apps. Uses P256 key agreement and AES‑GCM for per-transaction encryption; communicates with the Metal device over a local wireless radio link.
  3. Backend — Axum server, Postgres database, and payment pipeline that forwards valid requests to NIBSS NIP for settlement.

Throughput

~1.5 Mbps link

Optimized packet size (16 bytes) and chunking pipeline for deterministic transfers.

Latency

~950 ms (measured avg)

End-to-end exchange time for a full transaction handshake and transfer.

Core Components

At the firmware level the system is split into focused tasks:

  • Keypad Control — matrix scanning, debouncing, and price entry buffering.
  • LCD Display — dedicated thread receiving enum-based commands for concise rendering.
  • Pipe Stream — negotiates HTTPS with the cloud, performs health checks, and uploads transaction payloads.
  • Jinx — the transmission orchestrator that manages the chunked protocol, HEAD/MID/TAIL markers, and queues the assembled payload for Pipe Stream.
// sample thread spawn (Rust style) — simplified let thread1 = std::thread::Builder::new() .stack_size(7000) .spawn(move || keypad_control(state_one, cols, rows))?; let thread2 = std::thread::Builder::new() .stack_size(7000) .spawn(move || pipe_stream(state_two))?; // Jinx runs on main thread to remain continuously active

Transmission Protocol — "Jinx"

The protocol is designed for reliability over an unreliable wireless medium. Key ideas:

  • Fixed-size chunks (16 bytes): simplifies memory management on constrained devices.
  • HEAD / MID / TAIL markers: identify message boundaries, enabling incremental reassembly on the device side.
  • Acknowledgement loop: the mobile side writes a chunk and waits for a notification before sending the next chunk, preventing buffer overruns and silent drops.
  • LinkedList queue on mobile: divides large encrypted payloads into chunk nodes and enqueues them for reliable sequential writes.
// pseudocode: high level enqueue(HEAD); enqueue(MID...); enqueue(chunked(encrypted_payload)); enqueue(TAIL); while queue not empty: send(next_chunk) wait for ack

Security Model

Security balances strong guarantees with embedded constraints. The principal elements are:

  • Asymmetric keys: each customer receives a persistent P256 keypair. The public key is stored server-side and a compact encoding is stored in the device Keychain on mobile.
  • Ephemeral key agreement: mobile generates an ephemeral P256 key and performs ECDH with the customer public key, deriving a symmetric key (HKDF → AES‑GCM) per transaction.
  • AES‑GCM: chosen for combined authenticated encryption with associated data (AEAD) and low implementation complexity.
  • Device API keys: unique API key per METAL device used when uploading assembled transactions to the backend.

Why this combination? ECC for key agreement keeps public/private sizes small and computations feasible on mobile; AES‑GCM for symmetric encryption is efficient and widely supported across Swift and Rust when proper interoperability steps (x963 encodings, consistent HKDF parameters) are followed.

Implementation Details

Key implementation notes that influenced design choices:

  • no_std constraints on the firmware required careful static sizing (heapless Vec, fixed capacity buffers) and deterministic algorithms.
  • Thread synchronization uses Condvar + Mutex paired with Atomic flags to keep idle threads parked until needed, reducing power consumption.
  • HTTPS client on the ESM module uses a trusted CA bundle and a Caddy-backed server endpoint to simplify TLS on constrained hardware.
// simplified Rust: conditional wait let mut can_type = state.can_type.lock().unwrap(); loop { if !*can_type { can_type = state.cond_var.wait(can_type).unwrap(); } else { // perform work } FreeRtos::delay_ms(2); }

Challenges & Trade-offs

  • Cross-language cryptography: differences in library encodings (Swift vs Rust) required careful handling of public key representations and HKDF parameters.
  • ECC performance: on microcontrollers, ECC operations are expensive; choosing curves and offloading where appropriate mattered.
  • No single shared symmetric key: improved security but increased handshake overhead; mitigated by efficient ephemeral key agreement and chunking.
  • Physical transmission: calibrating link distance and timing for reliable discovery without accidental pairing with nearby devices required tuning of both radio power and protocol timeouts.

Evaluation & Results

After integration tests and field tests at small merchant locations, the measured averages were:

  • Average full exchange time: ~950 ms.
  • Chunk retransmit events: significantly reduced after introducing HEAD/T AIL markers and acknowledgment loop.
  • Power draw: device capable of multi-week operation on carefully sized battery with a conservative duty cycle and deep-sleep modes for idle periods.

Roadmap & Next Steps

Short-to-mid term priorities:

  1. Formalize NIBSS integration and compliance testing for NIP settlement.
  2. Iterate hardware: redesign PCB for lower BOM cost and optional satellite/wide-area modules.
  3. End-to-end interoperability tests for cross-language cryptography (Swift ↔ Rust) and hardened key handling.
  4. Scale dashboard features for merchant operations and device fleet management.

References & Credits

METAL was built using Rust (firmware), Swift (mobile helpers), Axum + Postgres (backend), and Svelte (website prototype). Core design and testing were led by TEAM METAL.