Skip to content
HeartBadge docs

SPV and Offline

Simplified Payment Verification, BEEF payloads, and how HeartBadge works without an internet connection.

HeartBadge is designed to work at the edge — at festival gates, transit fareboxes, and venues with unreliable connectivity. This page explains SPV (Simplified Payment Verification), BEEF payloads, and the offline verification model.

The problem

Most digital identity systems require a round trip to a server. You scan something, the reader calls an API, the API checks a database, the API returns a yes/no. This works fine when you have reliable connectivity.

It doesn't work when:

  • You're at a festival with 50,000 people and the cell network is overloaded
  • You're at a subway turnstile that needs sub-second verification
  • The venue's Wi-Fi is down
  • You're in an area with no internet at all

SPV: Simplified Payment Verification

SPV is a technique from Bitcoin that lets a verifier confirm a transaction is valid without downloading the entire blockchain. It works by:

  1. Header chain. The verifier has a copy of the block headers — small (80-byte) summaries of each block that form a chain of proof-of-work.
  2. Merkle proof. The transaction includes a Merkle proof — a cryptographic path from the transaction to the block header's Merkle root.
  3. Verification. The verifier checks that the Merkle proof is valid and that the block header is in the header chain. If both pass, the transaction is confirmed.

SPV doesn't require trusting a server. The math is self-proving.

BEEF: Background Evaluation Extended Format

BEEF extends SPV by packaging everything needed for verification into a single payload:

  • The transaction itself
  • All input transactions (to verify provenance)
  • Merkle proofs for each included transaction
  • Block headers (or references to known headers)

A BEEF payload is "self-proving" — it carries its own verification data. A reader with a header chain checkpoint can verify the entire payload without any network call.

How HeartBadge uses SPV

Badge verification

Your badge's current state is a UTXO on the OP_CAT Layer. When you scan at a reader, you present:

  1. Your badge identifier (from the rotating barcode)
  2. A BEEF payload proving your badge's current state

The reader verifies the BEEF payload against its header chain. If valid, the reader knows your badge is real, your ownership is current, and your state (HRTB tier, attestations) is accurate — all without calling a server.

Attestation verification

Attestations (check-ins, co-signs) also travel as BEEF. A verifier can confirm that an attestation was signed by an authorized PA and included in a block, all offline.

Reward state verification

The two-tier ledger means reward balances are settled on-chain. A BEEF payload can prove your last-settled balance. The difference between settled and current (the "in-flight" amount) is trusted from the fast tier — but for high-assurance checks, the settled balance is verifiable offline.

Header chain sync

Readers need a reasonably current header chain to verify recent transactions. Headers are small (~80 bytes each), so syncing is cheap:

  • On connect. When a reader gets internet access, it downloads any new headers since its last sync.
  • Periodic push. For high-availability readers (fareboxes), headers can be pushed via a secure channel.
  • Checkpoint fallback. A reader can always verify against an older checkpoint, with reduced recency guarantees.

Farebox-grade verification

The ultimate test is the transit farebox: a device that must verify in under 500ms, at a rate of one scan per second, with zero tolerance for false negatives (blocking legitimate riders) and very low tolerance for false positives (letting fraudulent scans through).

HeartBadge's SPV model is designed for this use case. The verification path is deterministic, the cryptography is fast, and the data is compact. A farebox can verify badges all day without ever calling home.

Related