Cowrie Research

bolt-card

3 min read

Bolt Card

  • Name: Bolt Card
  • URL: https://www.boltcard.org/
  • Category: contactless Bitcoin Lightning payment middleware / NFC card-and-service stack
  • Tags: bitcoin-ecosystem
  • Summary: Bolt Card is tap-to-pay Lightning middleware: NFC card credentials, a bolt card service, LNURL-withdraw flows, and merchant/POS plumbing. Real payment infrastructure, but still a narrow acceptance layer rather than a broader merchant stack.
  • What it does:
    • Lets customers tap an NFC card at a supporting point of sale to pay over the Bitcoin Lightning Network
    • Uses an operator-run bolt card service that receives merchant requests, enforces payment rules, and pays invoices from a connected Lightning node
    • Defines a full tap flow across customer card, merchant POS, merchant server, bolt card server, and separate Lightning nodes
    • Uses LNURL-withdraw card interactions via LUD-03 and raw lnurlw:// URLs via LUD-17
    • Supports self-hosted deployment plus automatic and manual card-creation workflows
    • Documents privacy levels, replay protection, and per-card controls such as enable flags, transaction limits, daily limits, and merchant allowlists
  • Key claims:
    • The official overview says each Bolt Card uses a bolt card service to receive requests from the merchant system, apply payment rules, and make payment
    • The GitHub README says the provided bolt card service software can be used to host bolt cards for yourself and others, which makes the project look like reusable operator infrastructure rather than a single card SKU
    • The system document says both customer and merchant need supporting infrastructure, with the POS talking to a merchant server that interacts with the customer’s bolt card server over LNURL-withdraw before payment reaches the Lightning network
    • The specification says Bolt Card is built on LUD-03 withdrawRequest, LUD-17 raw protocol URLs, NDEF, and replay protection using NXP Secure Unique NFC Message technology on NTAG 424 DNA cards
    • The specification says the bolt card service should decrypt and authenticate card values, accept only increasing counters, and can enforce policy such as enable flags, per-transaction and per-day limits, allowed merchants, or even location verification
    • The privacy document defines minimal, good, and best privacy levels based on whether static identifiers or plaintext UID values are exposed, explicitly treating point-of-sale tracking resistance as a first-class design concern
    • The FAQ says routing failures and latency depend heavily on the underlying Lightning node setup and notes that when tested with LND in November 2022 the paying and invoicing nodes needed to be separate instances
  • Whitepaper: No canonical standalone Bolt Card whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official site plus the first-party GitHub README, system overview, specification, privacy note, and FAQ; see ../whitepapers/bolt-card-primary-sources-2026-05-02.md.
  • Sources:

Internal linkages

  • Core Lightning URL-and-service substrate beneath the tap flow: lnurl
  • Stronger merchant-stack comparison for operators who want the checkout and settlement surface, not just the tap credential layer: btcpay-server

Control surface

  • The important leverage sits in the bolt card service: card issuance, key handling, counter validation, merchant allowlists, per-card spend limits, privacy mode, and the Lightning node that actually pays invoices.

  • Useful acceptance plumbing, but still just a tap-to-pay service layer sitting under stronger merchant and banking stacks.

  • Last reviewed: 2026-06-08 UTC

Graph View