SATSCARD Security Model

SATSCARD protects a sealed slot key inside an NFC smart card and lets compatible software verify card identity, state, and address derivation. Its security also depends on physical custody, the CVC, certificate-checking software, correct funding checks, and a trusted sweep workflow. Unsealing intentionally exposes the current slot key.

Security begins with the asset and lifecycle

The asset is the bitcoin controlled by the current slot. Before unsealing, the main goal is to keep that slot's private key unavailable while allowing the card and payment address to be checked. After unsealing, the goal changes: move every output promptly into a destination wallet whose backup and transaction controls you trust.

SATSCARD is therefore not secured like a display-equipped hardware wallet. It is a physical bearer instrument with a controlled, irreversible exit.

Key generation and chain-code verification

Each slot gets a fresh card-generated key contribution. For slots initialized after the factory slot, compatible software can supply a 32-byte chain code. The chain code and the card's secret contribution are combined through the protocol's BIP-32-based construction.

Because the application knows the chain code and can obtain the relevant public contribution, it can verify that the resulting payment address incorporates the expected inputs. This reduces the need to trust either the card or wallet as the only source of randomness. It is not a proof that all possible hardware and software faults are impossible.

Factory certificates

Each genuine card carries a factory certificate. A compatible app should verify that certificate against Coinkite's factory root before trusting card responses. The public reference implementation performs this check, and the protocol's best-practices document calls it a critical integration step.

A browser opened by a simple NFC tap verifies a dynamic signed link and provides convenient card-state information. For deeper verification, use protocol-aware software that checks the certificate and address construction directly.

CVC and encrypted NFC sessions

The six-digit card verification code authorizes protected operations and travels with the SATSCARD. The protocol uses an ephemeral ECDH-derived session to protect sensitive command data over NFC.

The CVC helps prevent a nearby reader from silently performing protected actions, but six digits are not a remote account password or a substitute for physical security. Keep the card in its RF-blocking sleeve when not in use, do not expose the CVC to cameras or untrusted apps, and do not hand over one without the other when transferring ownership.

Threats, controls, and limits

Threat	Protocol or user control	Limit
Copied static NFC URL	Fresh signed nonce in the verification link	A web tap is not every certificate/address check a full wallet can perform
Counterfeit card	Factory-certificate verification	Requires software that actually performs the check
Manipulated key generation	User/app chain-code contribution plus card entropy	Assumes correct implementation and protects no exposed old slot
Unauthorized protected command	CVC and encrypted NFC session	Physical theft plus CVC exposure remains dangerous
Previous holder copied a key	Accept only a sealed current slot; sweep when exclusivity matters	Custody history cannot be cryptographically erased
Malicious sweep software	Trusted device and independent destination-address verification	SATSCARD has no screen to verify the destination
RF probing	Fully inserted RF-blocking sleeve	Sleeve use does not replace custody or CVC secrecy

The unseal boundary

Normal inspection of a sealed slot does not reveal its private key. Unsealing is different by design: it makes the key available so software can spend the funds. Once that happens, the card cannot make the key secret again, and the slot cannot be resealed.

Treat the export like cash during transport. Use a trusted device, sweep to a verified address, confirm the transaction, and never fund the exposed address again. See How to unseal and sweep safely.

What SATSCARD cannot verify for you

SATSCARD has no display. It cannot independently show a sweep destination, fee, or transaction amount. It cannot decide how many confirmations are enough, prove safe behavior by every prior holder, prevent physical theft, or restore funds from an already spent slot.

For larger long-term savings, use a wallet architecture designed for that threat model, potentially including a display-equipped hardware wallet and multisignature. For routine bearer handoffs, apply the verify-and-accept checklist every time.

Open protocol and reviewability

Coinkite publishes the protocol, reference Python implementation, command-line tooling, and integration guidance. Open code makes independent implementation and review possible; it does not guarantee that every third-party wallet follows every best practice. Check the supported app's current behavior and version before relying on a critical workflow.

Start with What is SATSCARD?, or use SATSCARD vs TAPSIGNER to choose the correct product model.