Bitcoin-Wallet-PWA im nationalen Maßstab

Problem

Eine Consumer-Wallet im nationalen Maßstab kann keine reine native App sein und das Ledger nicht als private Demo behandeln. Menschen kommen aus einem Browser. Saldo, Senden und Empfangen müssen wacklige Netze überleben. Angrenzende Exchange- und BTM-Produkte brauchten dieselben Wallet-Primitive, ohne sie zu kopieren.

Vorgaben

Die Wallet musste als PWA funktionieren. Server-gerenderte Pfade mussten bleiben für Umgebungen, in denen das Client-Bundle nicht gegeben war. Ledger und HTTP-API mussten unter nebenläufiger Nutzung konsistent bleiben. Dieser Text nennt nicht das staatliche Deployment, zeigt keine Wallet-Oberfläche und beschreibt keine Custody-Interna.

Architektur

Eine React-PWA führte die Consumer-Sitzung: installierbar, diagrammfähig dort, wo die Exchange-Oberfläche es brauchte, und ausdrücklich über den Wallet-Zustand. Eine Django-API mit Postgres besaß Salden, Transfers und server-gerenderte Templates für die Nicht-SPA-Kante. Die Exchange-PWA (Angular) und die BTM-Vue-PWA nutzten dieselben Wallet-Muster wieder, statt ein zweites Ledger wachsen zu lassen. Animierte Kaufanleitungen auf dem BTM-Pfad waren nur Darstellung; die Abwicklung blieb auf der API.

Rolle

Ich habe die React-Wallet-PWA gebaut, die Django- und Postgres-API und die server-gerenderten Templates. Ich habe auch das Exchange-Frontend und den BTM-Kaufpfad ausgeliefert, damit die drei Oberflächen Wallet-Primitive teilten, statt sie zu forken.

Ergebnisse

• Ein browsernativer Wallet-Pfad, der keine Store-Installation verlangte.
• Eine API und ein Ledger hinter Wallet-, Exchange- und BTM-Oberflächen.
• Server-gerenderte Templates hielten die Nicht-SPA-Kante gegen dieselben Salden ehrlich.

Stack