SOVEREIGN CASH PROTOCOL
Trustless Offline Cryptocurrency Payments
Executive Summary
Sovereign Cash Protocol (SCP) enables trustless offline cryptocurrency payments using passive NFC cards costing under $1.50 each. By replacing expensive secure elements with economic security mechanisms inspired by Proof-of-Stake consensus, SCP makes physical crypto bearer instruments viable for the first time.
1.1 The Problem: Why Crypto Cash Doesn't Exist
Physical cash remains a dominant payment method for the majority of global transactions, especially in emerging markets. Yet cryptocurrency—designed to be "digital cash"—has no physical equivalent. The reason is a fundamental engineering paradox:
| Approach | Offline? | Card Cost | Trust Model | Crypto Settlement? |
|---|---|---|---|---|
| Traditional Crypto Wallets | ✗ No | N/A | Blockchain | ✓ Yes |
| Crypto Debit Cards | ✗ No | $3-5 | Centralized issuer | ✗ Fiat rails |
| Transit Cards (Oyster) | ✓ Yes | $5-15 | Secure element | ✗ No |
| Hardware Wallets (Tangem) | ✓ Partial | $30+ | Secure element | ✓ Yes |
| SCP ECHELON Cards | ✓ Yes | ~$1.50 | Economic security | ✓ Yes |
The core problem: offline stored-value requires tamper-proof hardware, which costs $5-30 per card. At these price points, disposable gift cards, mass transit, and unbanked populations cannot be served. SCP solves this by making fraud economically irrational rather than physically impossible.
1.2 The Solution: Economic Security for Physical Payments
SCP introduces a paradigm shift: instead of preventing fraud through expensive tamper-resistant hardware, we make fraud detectable and punishable through cryptographic proofs and economic penalties.
The system comprises three layers working in concert:
416 bytes · $1.50/card
Offline signing · Key mgmt
Bonds · Slashing · Finality
Every transaction creates a commitment chain—a hash-linked sequence of state transitions signed by registered merchants. When merchants submit transactions for settlement, the blockchain validates these chains. Any attempt to manipulate balances, replay transactions, or forge histories is cryptographically detectable and results in automatic slashing of the merchant's bonded collateral.
1.3 Key Innovation: Bonding/Slashing Instead of Secure Elements
The breakthrough insight of SCP is recognizing that physical payment security is an economic problem, not just a cryptographic one. Traditional systems ask: "How do we make fraud physically impossible?" SCP asks: "How do we make fraud economically irrational?"
If: Cost of fraud (slashed bond) > Potential profit from fraud
Then: Rational actors will not commit fraud
This model directly parallels Proof-of-Stake blockchain consensus:
| PoS Consensus | SCP Physical Payments |
|---|---|
| Validators stake tokens | Merchants stake bonds |
| Validators sign blocks | Merchants sign transactions |
| Invalid blocks → slashing | Fraudulent transactions → slashing |
| Other validators detect fraud | Settlement layer detects fraud |
| Finality after consensus | Finality after settlement |
The NTAG 424 DNA chip provides three critical guarantees that make this model work:
- SUN Authentication: Each tap generates a unique cryptographic proof (CMAC) bound to the chip's silicon. Cards cannot be cloned.
- Hardware Counter: A monotonic counter that only increments. Previous states cannot be restored.
- Authenticated Memory: 416 bytes of user memory protected by AES-128 encryption.
Combined with merchant signatures and commitment chains, these properties ensure that any fraud is detectable—and the merchant's bond provides the economic penalty that makes fraud irrational.
1.4 Target Markets & Use Cases
SCP addresses multiple trillion-dollar markets that remain underserved by existing payment infrastructure:
| Market | Global TAM | Pain Point | SCP Advantage |
|---|---|---|---|
| Remittances | $700B/year | 5-7% fees, 3-5 day delays | Instant settlement, <1% fees, no bank required |
| Unbanked Populations | ~1.4B people | No identity, no address, no bank access | Bearer instrument requires no account |
| Transit Systems | $180B/year | $8-15/card cost, vendor lock-in | <$2/card, open protocol, interoperable |
| Gift Cards | $2.5T/year | Fraud, breakage, centralized tracking | Crypto-backed, fraud-resistant, transparent |
| CBDC Distribution | Emerging | No offline solution, privacy concerns | True offline, programmable privacy tiers |
| Humanitarian Aid | $35B/year | Leakage, corruption, tracking difficulty | Auditable distribution, direct-to-recipient |
The ECHELON class system enables SCP to serve all these markets with appropriate risk parameters:
SCP is live today with a working MVP deployment. This whitepaper documents the complete technical specification of the protocol as implemented.
Introduction
2.1 The Bearer Instrument Gap
A bearer instrument is a financial asset where possession equals ownership. Physical cash is the archetypal bearer instrument: whoever holds the $20 bill owns $20 of value. No identity verification, no account lookup, no network connection—just hand over the paper and the transaction is complete.
This property makes cash uniquely powerful:
- Privacy: No transaction records, no data collection
- Resilience: Works during network outages, disasters, power failures
- Inclusion: No bank account, credit history, or identity documents required
- Finality: No chargebacks, no reversals, no disputes
- Speed: Instant settlement at point of transaction
Cryptocurrency was designed to bring these properties to the digital realm—Bitcoin's whitepaper explicitly describes "electronic cash." Yet a decade and a half later, no practical physical crypto bearer instrument exists.
The gap persists because creating a physical bearer instrument requires solving an impossible-sounding problem: how do you store value in a physical object such that:
- The balance can be verified without network access
- Spending reduces the balance (no double-spending)
- The balance cannot be arbitrarily increased
- The object cannot be duplicated/cloned
- The object is cheap enough for mass deployment
Traditional solutions achieve properties 1-4 through secure elements—tamper-resistant chips that refuse to operate if physically compromised. But secure elements cost $5-30 per unit, failing requirement 5. SCP solves all five requirements through economic security.
2.2 Why Existing Solutions Fail
2.2.1 Transit Cards (Oyster, Suica, OMNY)
Transit fare cards like London's Oyster, Japan's Suica, and New York's OMNY represent the most successful deployment of offline stored-value cards. They achieve true offline operation through MIFARE DESFire or similar secure element chips.
| System | Chip | Card Cost | Offline? | Open Protocol? |
|---|---|---|---|---|
| Oyster (London) | MIFARE DESFire | ~$8 | ✓ | ✗ Proprietary |
| Suica (Japan) | FeliCa | ~$10 | ✓ | ✗ Proprietary |
| OMNY (NYC) | EMV Contactless | N/A (uses credit cards) | ✗ Online auth | ✗ Visa/MC rails |
Limitations: These systems are closed, proprietary, centrally controlled, and non-interoperable. A Suica card is worthless in London. Value is denominated in fiat and cannot settle to cryptocurrency. Most critically, the secure element costs make them unsuitable for disposable applications like gift cards or humanitarian aid distribution.
2.2.2 Crypto Payment Cards (BoltCard, LNBits)
The BoltCard project pioneered using NTAG 424 DNA chips for Lightning Network payments. When tapped, the card generates a URL containing a cryptographic proof that triggers a Lightning payment via LNURL-withdraw.
Card Tap → CMAC URL → Internet → LNURL Server → Lightning Invoice → Payment
Limitations: BoltCard is not a stored-value card—it's a payment authorization device. The balance lives on the LNURL server, not the card. This means:
- Requires internet connectivity for every transaction
- Server compromise = total fund loss
- Centralized trust in the LNURL operator
- Not a true bearer instrument (server controls funds)
BoltCard is useful for convenient Lightning spending but does not solve the offline bearer instrument problem.
2.2.3 Hardware Wallets (Tangem, CoolWallet)
Hardware wallet cards like Tangem embed secure elements capable of signing cryptocurrency transactions. The card holds private keys in tamper-resistant silicon and signs transactions when tapped.
Limitations:
- Cost: $30-50 per card due to secure element
- Not stored-value: Signs transactions, doesn't store balance
- Still requires connectivity: Signed transaction must be broadcast to blockchain
- User experience: Requires smartphone app, blockchain confirmations
Tangem solves key custody, not offline payments. A Tangem card cannot pay for coffee without smartphone connectivity and blockchain confirmation.
2.2.4 EMV Contactless
Traditional contactless credit/debit cards (Visa payWave, Mastercard PayPass) use EMV chip technology. While they appear to work "offline," they actually operate in two modes:
- Online mode: Terminal contacts issuer for authorization (default for most transactions)
- Offline mode: Terminal trusts card's cryptographic signature (limited to small amounts, requires periodic online refresh)
Even in offline mode, EMV is not a bearer instrument—the card is an authentication device, not a value store. The issuer controls the account and can reverse transactions, freeze funds, or close accounts. This is the fundamental distinction: EMV cards authorize access to an account; SCP cards ARE the account.
2.2.5 CBDC Proposals
Central banks worldwide are exploring CBDCs (Central Bank Digital Currencies). Most designs assume either:
- Account-based systems requiring identity verification
- Token-based systems requiring secure hardware
- Online-only operation
The ECB, Fed, and Bank of England have all identified "offline capability" as a critical requirement for CBDCs, yet no production-ready solution exists. SCP's ECHELON Platinum tier is specifically designed for CBDC deployment, offering true offline operation without expensive secure elements.
2.3 Design Goals & Constraints
SCP is designed against the following requirements, derived from real-world deployment scenarios:
| Requirement | Target | Rationale |
|---|---|---|
| Card Cost | < $2.00 | Enables gift cards, transit, disposable applications |
| Offline Operation | 100% | Payment completes without any network connectivity |
| Transaction Speed | < 500ms | Competitive with contactless payments |
| Settlement Finality | 1-24 hours | Merchant receives crypto, fraud window closes |
| Fraud Loss | 0% | Economic security ensures fraudster loses more than gains |
| Scalability | 1B+ cards | Global deployment potential |
| Decentralization | No single point of failure | Multiple issuers, open protocol |
| Crypto Settlement | Native | Merchants receive cryptocurrency, not fiat IOUs |
These constraints eliminate most existing approaches and necessitate the novel economic security model that defines SCP.
2.4 Threat Model Overview
SCP is designed to resist the following adversary capabilities:
- Cloning cards
- Reading/modifying memory
- Restoring previous balances
- Double-spending
- Inflating balances
- Forging transactions
- Colluding with cardholders
- Withholding settlements
- Eavesdropping NFC
- Man-in-the-middle
- Replay attacks
- Settlement manipulation
SCP assumes:
- NTAG 424 DNA silicon security is sound (NXP's guarantee)
- AES-128 and SHA-256 are cryptographically secure
- Stellar blockchain operates correctly
- Economic actors are rational (prefer profit over loss)
Section 8 provides detailed security analysis of each attack vector and the specific mitigations employed.
System Architecture
3.1 Three-Tier Model Overview
SCP implements a layered architecture where each tier handles specific responsibilities. This separation enables offline operation while maintaining cryptographic accountability:
The key insight is that trust flows upward through cryptographic proofs. The card cannot be cloned (SUN), the terminal cannot forge transactions (merchant signatures), and the settlement layer cannot be deceived (commitment chain validation). Each layer provides guarantees that the layer above can verify.
3.2 Tier 1: Card Layer
The card layer is the physical bearer instrument—the object that stores and transfers value. SCP uses NXP's NTAG 424 DNA chip, selected after extensive evaluation of available NFC technologies.
3.2.1 NTAG 424 DNA Selection Rationale
| NFC Chip | Memory | Crypto Auth | Counter | Unit Cost | SCP Compatible |
|---|---|---|---|---|---|
| NTAG 213/215/216 | 144-888B | ✗ None | ✗ No | $0.15 | ✗ No auth |
| MIFARE Ultralight | 64-192B | ✗ None | ✓ Yes | $0.20 | ✗ No auth |
| MIFARE Classic | 1-4KB | ✗ Broken | ✗ No | $0.50 | ✗ Insecure |
| MIFARE DESFire EV2 | 2-8KB | ✓ AES | ✓ Yes | $2-5 | ✗ Too expensive |
| NTAG 424 DNA | 416B | ✓ SUN/CMAC | ✓ Yes | $0.80-1.50 | ✓ Ideal |
NTAG 424 DNA provides the optimal combination of security features and cost. Its SUN (Secure Unique NFC) authentication generates cryptographic proofs that cannot be forged without access to the physical silicon.
3.2.2 SUN (Secure Unique NFC) Authentication
SUN authentication is the foundation of card authenticity in SCP. Each time the card is tapped, it generates a unique message containing:
SUN Message Structure:
┌────────────────────────────────────────────────────────┐
│ UID (7 bytes) │ Counter (3 bytes) │ CMAC (8 bytes) │
└────────────────────────────────────────────────────────┘
CMAC = AES-CMAC(SDM_Key, UID || Counter || RandomPadding)
Critical properties of SUN:
- Unique per tap: Counter increments, producing different CMAC each time
- Unforgeable: CMAC requires SDM key stored in tamper-resistant silicon
- UID-bound: CMAC is specific to this chip's unique identifier
- Verifiable offline: Terminal can verify CMAC with pre-shared key
An attacker who reads all card memory still cannot produce valid SUN messages. The CMAC computation occurs inside the NTAG 424's silicon using a key that cannot be extracted. Copying data to another chip produces a different UID and invalid CMACs.
3.2.3 Hardware Counter Guarantees
NTAG 424 DNA includes a 24-bit hardware counter with critical properties:
- Monotonic: Counter only increments, never decrements
- Non-volatile: Value persists through power cycles
- Tamper-evident: Physical attacks destroy the chip
- Range: 0 to 16,777,215 (sufficient for 45+ years at 1 tap/minute)
The counter provides anti-rollback protection. If a cardholder backs up card state, spends money, then restores the backup, the counter will be lower than the terminal expects. This immediately reveals the attempted fraud.
Anti-Rollback Check:
IF card.counter <= terminal.last_seen_counter[card.uid] THEN
REJECT "Counter rollback detected"
FLAG card for investigation
END IF
3.2.4 Memory Layout (416 Bytes)
NTAG 424 DNA provides 416 bytes of user-accessible memory. SCP allocates this space as follows:
This allocation is carefully optimized: the header is write-once (set at issuance), the state updates with each transaction, and the log maintains a rolling window of recent transactions for fraud detection. Section 4 provides byte-level specifications.
3.3 Tier 2: Terminal Layer
The terminal layer is the merchant's point-of-sale system. It reads cards, validates state, constructs new transactions, and writes updated state back to cards. Critically, terminals operate completely offline during transactions.
3.3.1 Merchant Terminal Requirements
| Component | Requirement | Purpose |
|---|---|---|
| NFC Reader | ISO 14443-A, Extended APDU | Card communication |
| Processor | ARM Cortex-M4+ or equivalent | Crypto operations |
| Secure Storage | TPM, HSM, or encrypted keystore | Merchant key protection |
| Clock | RTC with battery backup | Timestamp transactions |
| Storage | ≥1GB non-volatile | Transaction queue |
| Connectivity | Periodic (daily minimum) | Settlement submission |
Reference implementations support Android (with NFC), dedicated POS hardware, and desktop applications with USB NFC readers (ACR1252U recommended for development).
3.3.2 Key Management & Secure Enclaves
Each merchant terminal holds a unique Ed25519 keypair. The private key signs every transaction, creating non-repudiable proof of the merchant's involvement. Key security is critical:
Key compromise is catastrophic—it allows unlimited transaction forgery until detected. Merchants are financially liable for transactions signed by their key, incentivizing proper key security.
3.3.3 Offline Transaction Signing
The terminal processes payments through a state machine that requires no network access:
TRANSACTION FLOW (Offline):
1. READ → Terminal reads card SUN message + memory
2. VERIFY → Validate CMAC, counter, state_hash chain
3. CHECK → Confirm balance ≥ payment amount
4. COMPUTE → Calculate new_balance, new_state_hash
5. SIGN → Ed25519 signature over state transition
6. WRITE → Update card state + append to transaction log
7. CONFIRM → Read back and verify write success
8. QUEUE → Store transaction locally for settlement
The entire process completes in under 500ms. The terminal queues transactions locally until connectivity is available for settlement submission.
3.3.4 State Validation Logic
Before accepting any payment, the terminal validates the card's current state:
VALIDATION CHECKS:
□ SUN CMAC valid for this UID + counter
□ Counter > last seen counter for this card (anti-replay)
□ state_hash = H(prev_hash || prev_balance || prev_counter || prev_merchant)
□ last_sig verifies against last_merchant's registered pubkey
□ balance ≤ denomination (max card capacity)
□ balance ≥ requested payment amount
□ Card not in revocation list (if online recently)
ALL checks must pass → Accept payment
ANY check fails → Reject + log anomaly
These checks ensure the card has not been tampered with, rolled back, or presented with a forged history. The state_hash chain provides cryptographic proof of all prior transactions.
3.4 Tier 3: Settlement Layer
The settlement layer provides global state, economic enforcement, and finality. It runs on the Stellar network using Soroban smart contracts, chosen for fast finality (~5 seconds), low fees (~$0.0001), and battle-tested infrastructure.
3.4.1 Blockchain Selection (Stellar/Soroban)
| Blockchain | Finality | Tx Cost | Smart Contracts | TPS |
|---|---|---|---|---|
| Bitcoin | ~60 min | $0.50-20 | Limited | ~7 |
| Ethereum (L1) | ~12 min | $0.50-50 | Full (EVM) | ~30 |
| Solana | ~0.4s | $0.001 | Full (Rust) | ~65,000 |
| Stellar/Soroban | ~5s | $0.0001 | Full (Rust) | ~10,000 |
Stellar's Stellar Consensus Protocol (SCP) provides deterministic finality without forks. Once a transaction is confirmed, it cannot be reversed. This property is essential for settlement layer security.
3.4.2 Card Registry Contract
The Card Registry maintains the authoritative state for all SCP cards:
CardRegistry Contract Interface:
register_card(card_id, issuer, denomination, echelon_class)
→ Registers new card, stores initial state_hash
get_card_state(card_id)
→ Returns {balance, state_hash, last_counter, status}
submit_settlement(card_id, transactions[], merchant_sigs[])
→ Validates chain, updates state, credits merchant
revoke_card(card_id, reason)
→ Marks card invalid, triggers refund process
The registry serves as the source of truth for disputed transactions. If two merchants submit conflicting histories for the same card, the registry determines which is valid and slashes the fraudulent party.
3.4.3 Merchant Bond Contract
The Bond Contract manages merchant staking and slashing:
MerchantBond Contract Interface:
register_merchant(pubkey, echelon_class)
→ Registers merchant public key
deposit_bond(merchant_id, amount)
→ Locks funds as collateral
request_withdrawal(merchant_id, amount)
→ Initiates unbonding period (7-30 days)
slash(merchant_id, amount, evidence)
→ Penalizes fraud, distributes to victim + reporter
get_bond_status(merchant_id)
→ Returns {bonded, pending_withdrawal, slashed_history}
Bond requirements scale with ECHELON class—merchants accepting higher-value cards must stake more collateral. This ensures fraud is always economically irrational regardless of card denomination.
3.4.4 Fraud Detection Engine
The Fraud Detection Engine automatically identifies protocol violations during settlement:
- Double-spend detection: Same counter value with different state transitions
- Balance inflation: Balance increases without corresponding credit transaction
- Chain fork: Two valid-looking chains diverge from the same state
- Counter regression: Submitted counter lower than last settled counter
- Invalid signature: Merchant signature doesn't match registered key
When fraud is detected, the engine automatically triggers slashing. The merchant responsible (identified by their signature) loses a portion of their bond. A portion goes to the victim, a portion to the fraud reporter, and a portion to the protocol treasury.
3.4.5 Settlement & Reconciliation
Merchants submit batched transactions for settlement on a regular schedule determined by their ECHELON class:
| ECHELON Class | Settlement Frequency | Max Batch Size | Fraud Window |
|---|---|---|---|
| Bronze | Daily | 1,000 tx | 24 hours |
| Silver | Twice daily | 5,000 tx | 12 hours |
| Gold | Hourly | 10,000 tx | 1 hour |
| Platinum | Real-time | Unlimited | ~5 seconds |
Upon successful settlement, the merchant's account is credited with the transaction amounts (minus protocol fees). Failed validations result in transaction rejection and potential slashing.
Card Data Model
4.1 Data Structure Overview
The 416-byte card memory is divided into three segments, each serving a distinct purpose in the security model. Every byte is carefully allocated to maximize fraud detectability while minimizing storage requirements.
┌─────────────────────────────────────────────────────────────────┐
│ SCP CARD DATA STRUCTURE │
├─────────────────────────────────────────────────────────────────┤
│ Offset │ Size │ Field │ Description │
├─────────┼─────────┼─────────────────────┼───────────────────────┤
│ 0x000 │ 32 B │ HEADER │ Immutable card identity │
│ 0x020 │ 64 B │ CURRENT_STATE │ Mutable balance/proofs │
│ 0x060 │ 320 B │ TRANSACTION_LOG │ Rolling 10-entry history│
├─────────┴─────────┴─────────────────────┴───────────────────────┤
│ TOTAL: 416 BYTES │
└─────────────────────────────────────────────────────────────────┘
- Minimal storage: Every byte serves a security purpose
- Self-contained verification: Card contains all data needed to validate state
- Forward compatibility: Version field enables future upgrades
- Fraud attribution: Every state change is signed and traceable
4.2 Card Header (32 bytes)
The header is written once at card issuance and never modified. It establishes the card's identity, capacity, and trust anchor.
4.2.1 card_id
The 8-byte card identifier is derived from the NTAG 424's 7-byte UID combined with an issuer namespace byte:
card_id = issuer_namespace_byte || NTAG_UID[7 bytes]
This ensures card_id uniqueness across issuers. The card_id is the primary key in the settlement layer's Card Registry.
4.2.2 issuer_id
The 8-byte issuer identifier is the first 8 bytes of the SHA-256 hash of the issuer's Stellar public key:
issuer_id = SHA256(issuer_stellar_pubkey)[0:8]
This allows terminals to verify the issuer's identity and retrieve the issuer's public key from the settlement layer if needed.
4.2.3 denomination
A 32-bit unsigned integer representing the maximum card capacity in base units (satoshis for Bitcoin-backed cards, stroops for XLM-backed cards). The denomination determines:
- Maximum balance the card can hold
- Merchant bond requirements (merchants must stake collateral ≥ max card denomination)
- Which ECHELON class merchants can accept this card
| ECHELON Class | Max Denomination | USD Equivalent |
|---|---|---|
| Bronze | 500,000 sats | ~$500 |
| Silver | 5,000,000 sats | ~$5,000 |
| Gold | 50,000,000 sats | ~$50,000 |
| Platinum | Custom | Unlimited |
4.2.4 issued_at
A 32-bit Unix timestamp recording when the card was issued. Used for:
- Expiration calculation (if issuer enforces card lifetimes)
- Audit trails and fraud investigation
- Rate-limiting card issuance
4.2.5 echelon_class
A single byte indicating the card's security tier:
0x01 = ECHELON Bronze (Consumer)
0x02 = ECHELON Silver (Business)
0x03 = ECHELON Gold (Enterprise)
0x04 = ECHELON Platinum (Government/CBDC)
The ECHELON class determines settlement priority, merchant requirements, and applicable fraud detection rules.
4.3 Current State (64 bytes)
The state segment is updated with every transaction. It contains the current balance and cryptographic proofs linking to the entire transaction history.
4.3.1 balance
A 64-bit unsigned integer representing the current card balance in base units. The balance must always satisfy:
0 ≤ balance ≤ header.denomination
Any transaction that would violate this constraint is rejected by terminals.
4.3.2 state_hash (Commitment Chain)
The 32-byte state_hash is the cryptographic anchor of SCP's security model. It is a SHA-256 hash that chains the current state to all previous states:
state_hash[n] = SHA256(
state_hash[n-1] || // Previous hash (32B)
balance[n] || // New balance (8B)
counter[n] || // Counter value (4B)
merchant_id[n] || // Merchant (8B)
amount[n] || // Transaction amount (8B)
timestamp[n] // Unix time (4B)
)
This creates an unforgeable chain of custody. To produce a valid state_hash[n], an attacker must know state_hash[n-1], which requires knowing state_hash[n-2], and so on back to the initial state set at issuance.
Any modification to historical transactions changes all subsequent hashes, causing verification to fail. An attacker cannot create an alternate history without either (a) breaking SHA-256, or (b) knowing the initial state_hash[0] set during card issuance, which is recorded on-chain.
4.3.3 last_counter
The 32-bit counter value at the time of the last transaction. This is cross-referenced with the NTAG 424's hardware counter to detect rollback attempts:
- If
hardware_counter < last_counter: Impossible (hardware cannot decrement) - If
hardware_counter == last_counter: Replay attempt detected - If
hardware_counter > last_counter: Valid new transaction
4.3.4 last_merchant
The 8-byte identifier of the last merchant to modify this card. Computed as:
last_merchant = SHA256(merchant_ed25519_pubkey)[0:8]
This enables fraud attribution—if the current state is invalid, the last_merchant is responsible.
4.3.5 last_sig
The first 8 bytes of the merchant's Ed25519 signature over the state transition. The full 64-byte signature is stored in the transaction log and submitted during settlement.
Truncation to 8 bytes provides sufficient fraud attribution (probability of collision: 2-64) while conserving card memory. The full signature is required for on-chain verification.
4.4 Transaction Log (320 bytes)
The transaction log maintains a rolling history of the last 10 transactions. This provides sufficient data for fraud detection during the settlement window.
4.4.1 Log Entry Structure
Each log entry is exactly 32 bytes, allowing 10 entries in 320 bytes:
4.4.2 Circular Buffer Implementation
The transaction log is implemented as a circular buffer. A 1-byte head pointer (stored in the flags field of the header) indicates the next write position:
write_position = (head_pointer % 10) * 32 + 0x60
head_pointer = (head_pointer + 1) % 256
When the buffer is full, new entries overwrite the oldest. This is acceptable because settlement occurs within the fraud window (1-24 hours depending on ECHELON class), and merchants retain full transaction records locally.
4.4.3 Truncated Signatures
Log entries use 7-byte truncated signatures to conserve space. The truncation provides:
- 256 collision resistance: Sufficient for fraud attribution
- Full signature stored elsewhere: Merchants keep complete records
- Settlement verification: On-chain validation uses full signatures
The truncated signature is the first 7 bytes of: Ed25519_Sign(merchant_privkey, state_transition_data)
4.5 Encoding & Serialization
All multi-byte integers are stored in big-endian (network byte order). This ensures consistent interpretation across platforms and simplifies debugging when examining raw card data.
ENCODING RULES:
• Integers: Big-endian (most significant byte first)
• Hashes: Raw bytes (not hex-encoded)
• Signatures: Raw bytes (not base64-encoded)
• Timestamps: 32-bit Unix epoch (seconds since 1970-01-01)
• Padding: Zero-filled for reserved/alignment bytes
• Strings: Not used (all fields are fixed-width binary)
Version compatibility: The header version field (currently 0x01) allows future protocol upgrades. Terminals encountering unknown versions must reject the card and report to the settlement layer.
Cryptographic Protocols
SCP uses industry-standard primitives: AES-128-CMAC for card authentication, SHA-256 for hashing, Ed25519 for signatures, and HKDF-SHA256 for key derivation. No custom or experimental cryptography is employed.
5.1 Key Derivation
SCP employs a hierarchical key derivation scheme that enables secure key management while minimizing the blast radius of key compromise.
5.1.1 Issuer Master Key
Each card issuer generates a 256-bit master key during initial setup. This key is the root of all card-specific keys and must be protected with the highest security measures:
ISSUER KEY GENERATION:
issuer_master_key = CSPRNG(256 bits)
issuer_pubkey = Ed25519_PublicKey(issuer_master_key)
STORAGE REQUIREMENTS:
• ECHELON Bronze/Silver: HSM or encrypted backup (min AES-256)
• ECHELON Gold/Platinum: FIPS 140-2 Level 3+ HSM mandatory
If the issuer master key is compromised, all cards issued by that issuer must be revoked. The attacker could derive SDM keys for any card and produce valid CMAC messages. This is why HSM storage is mandatory for high-value deployments.
5.1.2 Card-Specific Key Derivation
Each card receives unique cryptographic keys derived from the issuer master key and the card's UID. This ensures that compromising one card reveals nothing about other cards:
CARD KEY DERIVATION (HKDF-SHA256):
// Input Key Material
ikm = issuer_master_key
// Salt (public, unique per card)
salt = "SCP-v1" || card_uid || issued_at
// Derived Keys
card_sdm_key = HKDF-Expand(ikm, salt || "SDM", 16) // AES-128 for SUN
card_enc_key = HKDF-Expand(ikm, salt || "ENC", 16) // AES-128 for memory
card_mac_key = HKDF-Expand(ikm, salt || "MAC", 16) // CMAC verification
The card_sdm_key is programmed into the NTAG 424's secure key slot during issuance. This key never leaves the chip after programming—all subsequent authentication occurs within the silicon.
HKDF-SHA256
│
5.1.3 Merchant Key Registration
Merchants generate their own Ed25519 keypairs and register the public key on-chain. This creates a binding between the merchant's identity, their bond, and their signing key:
MERCHANT KEY REGISTRATION:
1. Generate keypair locally:
merchant_privkey = Ed25519_Generate()
merchant_pubkey = Ed25519_PublicKey(merchant_privkey)
2. Compute merchant_id:
merchant_id = SHA256(merchant_pubkey)[0:8]
3. Register on-chain (requires bond deposit):
MerchantBond.register(merchant_pubkey, echelon_class, bond_amount)
4. Store privkey securely:
HSM, TEE, or encrypted keystore depending on ECHELON class
The on-chain registration creates an immutable link: any transaction signed by merchant_privkey is attributable to the merchant's bonded account. Fraud results in slashing that specific bond.
5.2 SUN Message Authentication
SUN (Secure Unique NFC) is the NTAG 424 DNA's mechanism for proving card authenticity. Each tap generates a cryptographic message that can only be produced by the genuine silicon.
5.2.1 CMAC Generation
The NTAG 424 computes an AES-128-CMAC over a structured message containing dynamic elements:
SUN CMAC COMPUTATION (inside NTAG 424 silicon):
input_data = {
uid: 7 bytes // Chip's unique identifier
read_counter: 3 bytes // Current counter value (big-endian)
random_data: ? bytes // Optional random padding
}
cmac = AES-128-CMAC(card_sdm_key, input_data)
// Output: First 8 bytes of CMAC (truncated for NFC URL length)
sun_message = Base64URL(uid || read_counter || cmac[0:8])
The CMAC algorithm (defined in NIST SP 800-38B) provides 64 bits of security after truncation—sufficient for authentication purposes since each CMAC is valid only once (counter increments).
5.2.2 UID Binding
The card's 7-byte UID is embedded in the CMAC computation. This creates a binding between the authentication message and the specific physical chip:
- Cloning prevention: A copied CMAC won't verify against a different chip's UID
- Card identification: Terminal extracts UID from SUN message to look up card state
- Audit trail: UID provides forensic linkage to physical card
An attacker who intercepts a SUN message cannot use it with a different card. When they present a cloned card with a different UID, the terminal computes the expected CMAC using the clone's UID and card_sdm_key. Since the clone has a different UID, the expected CMAC won't match the captured one. The attacker would need the original chip's SDM key, which cannot be extracted from the silicon.
5.2.3 Counter Binding
The hardware counter value is included in the CMAC computation, providing freshness and replay protection:
| Scenario | Counter Check | Result |
|---|---|---|
| First presentation | counter > last_seen | ✓ Accept |
| Replay same tap | counter == last_seen | ✗ Reject (replay) |
| Restored backup | counter < last_seen | ✗ Impossible (HW) |
| Skipped counter | counter >> last_seen | ⚠ Flag for review |
The counter binding ensures that even if an attacker captures a SUN message, it cannot be replayed—the terminal will have already recorded that counter value as "seen."
5.3 Commitment Chain Construction
The commitment chain is the cryptographic data structure that enables fraud detection. It creates an unforgeable history of all card state transitions.
5.3.1 State Hash Algorithm
Each state transition produces a new hash that incorporates all previous history:
STATE HASH COMPUTATION:
function compute_state_hash(prev_state, transaction) {
input = concat(
prev_state.state_hash, // 32 bytes - chain anchor
transaction.new_balance, // 8 bytes
transaction.counter, // 4 bytes
transaction.merchant_id, // 8 bytes
transaction.amount, // 8 bytes
transaction.tx_type, // 1 byte
transaction.timestamp // 4 bytes
); // Total: 65 bytes
return SHA256(input); // 32 bytes output
}
5.3.2 Chain Integrity Verification
During settlement, the chain is verified by recomputing hashes from submitted transactions:
CHAIN VERIFICATION ALGORITHM:
function verify_chain(card_id, transactions[]) {
// Get genesis hash from on-chain registry
expected_hash = CardRegistry.get_initial_hash(card_id)
for tx in transactions {
// Recompute hash
computed_hash = compute_state_hash(expected_hash, tx)
// Verify merchant signature
if !verify_signature(tx.merchant_pubkey, tx, tx.signature) {
return FRAUD_DETECTED(tx.merchant_id, "invalid_signature")
}
// Verify counter monotonicity
if tx.counter <= prev_counter {
return FRAUD_DETECTED(tx.merchant_id, "counter_violation")
}
expected_hash = computed_hash
prev_counter = tx.counter
}
return VALID(expected_hash)
}
5.3.3 Fork Detection
A fork occurs when two different transaction histories branch from the same state. This indicates fraud—someone created an alternate history:
Fork detection triggers an investigation. The fraud engine examines both branches to determine which merchant(s) signed invalid transactions. Slashing is applied to the responsible party.
5.4 Transaction Signatures
Every state transition is signed by the merchant who authorized it. These signatures provide non-repudiation and enable fraud attribution.
5.4.1 Signature Scheme Selection
SCP uses Ed25519 (EdDSA over Curve25519) for all merchant signatures:
| Property | Ed25519 | ECDSA (secp256k1) | RSA-2048 |
|---|---|---|---|
| Public key size | 32 bytes | 33 bytes | 256 bytes |
| Signature size | 64 bytes | 64-72 bytes | 256 bytes |
| Sign speed | ~15,000/sec | ~5,000/sec | ~1,000/sec |
| Verify speed | ~7,000/sec | ~3,000/sec | ~30,000/sec |
| Deterministic | ✓ Yes | RFC 6979 needed | ✓ Yes |
Ed25519's deterministic signatures are particularly important—they eliminate the risk of nonce reuse vulnerabilities that have plagued ECDSA implementations.
5.4.2 Truncation Strategy
Due to card memory constraints, signatures are stored in truncated form on the card:
SIGNATURE STORAGE:
// Full signature (generated by merchant, stored in terminal)
full_sig = Ed25519_Sign(merchant_privkey, state_transition) // 64 bytes
// Truncated for card state (section 4.3.5)
last_sig = full_sig[0:8] // 8 bytes, 2⁶⁴ collision resistance
// Truncated for log entries (section 4.4.1)
log_sig = full_sig[0:7] // 7 bytes, 2⁵⁶ collision resistance
Security analysis: Truncation does not reduce signature security—an attacker cannot forge signatures with fewer bits. The truncation only affects collision resistance (probability of two different messages having the same truncated signature). With 256 - 264 collision resistance and single-use signatures (each bound to a unique counter), truncation is safe.
5.4.3 Signature Verification
On-chain verification uses full signatures submitted by merchants during settlement:
SIGNATURE VERIFICATION PROCESS:
function verify_transaction_signature(tx, merchant_pubkey) {
// Reconstruct signed message
message = concat(
tx.prev_state_hash, // 32 bytes
tx.new_balance, // 8 bytes
tx.counter, // 4 bytes
tx.amount, // 8 bytes
tx.tx_type, // 1 byte
tx.timestamp, // 4 bytes
tx.card_id // 8 bytes
);
return Ed25519_Verify(merchant_pubkey, message, tx.full_signature);
}
The card_id is included in the signed message to prevent signature replay across cards. A valid signature for Card A cannot be used to modify Card B.
Economic Security Model
SCP's security does not rely on making fraud impossible—it relies on making fraud economically irrational. When the cost of fraud (slashed bond) exceeds the potential profit, rational actors choose honesty.
6.1 Proof-of-Stake Inspiration
SCP's economic security model is directly inspired by Proof-of-Stake blockchain consensus. The key insight: if validators (or merchants) have "skin in the game," they are economically incentivized to behave honestly.
| Concept | PoS Blockchain | SCP Physical Payments |
|---|---|---|
| Collateral | Validators stake tokens | Merchants stake bonds |
| Work | Validators propose/attest blocks | Merchants sign transactions |
| Verification | Other validators check blocks | Settlement layer validates chains |
| Punishment | Invalid blocks → slashing | Fraudulent transactions → slashing |
| Reward | Block rewards + fees | Transaction fees + customer revenue |
| Finality | After sufficient attestations | After settlement confirmation |
The critical difference: PoS operates in a fully digital environment where all state is on-chain. SCP bridges the physical-digital gap—cards exist in the real world, but economic enforcement happens on-chain. The commitment chain provides the cryptographic proof that connects physical card state to on-chain verification.
6.2 Merchant Bonding
Before processing SCP transactions, merchants must deposit collateral (a "bond") into the on-chain Merchant Bond Contract. This bond serves as the economic guarantee backing their transaction signatures.
6.2.1 Bond Requirements by ECHELON Class
Bond requirements scale with the maximum card denomination a merchant can accept:
| ECHELON Class | Max Card Value | Minimum Bond | Bond Ratio | Target Merchants |
|---|---|---|---|---|
| Bronze | $500 | $1,000 | 2x | Street vendors, small retail |
| Silver | $5,000 | $10,000 | 2x | Restaurants, mid-size retail |
| Gold | $50,000 | $100,000 | 2x | Luxury retail, B2B |
| Platinum | Custom | $1,000,000+ | Negotiated | Government, institutions |
The 2x bond ratio ensures that even if a merchant commits maximum fraud (inflating a card to its full denomination), the slashed bond exceeds the fraudulent gain. This makes fraud a losing proposition.
6.2.2 Staking Mechanics
Bonds are deposited in the protocol's native token or approved stablecoins:
BOND DEPOSIT FLOW:
1. Merchant generates Ed25519 keypair
2. Merchant calls MerchantBond.register(pubkey, echelon_class)
3. Merchant transfers bond amount to contract
4. Contract verifies amount ≥ minimum for echelon_class
5. Contract activates merchant status
6. Merchant can now sign SCP transactions
ACCEPTED COLLATERAL:
• USDC (preferred) - stable value
• XLM - native Stellar asset
• Protocol token - governance + staking
Bonds earn yield while staked—a portion of protocol fees is distributed to bonded merchants proportional to their stake. This creates positive economics for honest participation.
6.2.3 Bond Lifecycle
The unbonding period (7-30 days depending on ECHELON class) ensures that merchants cannot quickly withdraw funds after committing fraud. All pending transactions must settle before funds are released, allowing time for fraud detection.
6.3 Slashing Conditions
Slashing is the automatic penalty applied when fraud is cryptographically proven. The merchant's bond is reduced, with portions distributed to victims and fraud reporters.
6.3.1 Detectable Fraud Types
| Fraud Type | Detection Method | Severity | Slash Amount |
|---|---|---|---|
| Balance Inflation | Balance increased without valid credit tx | Critical | 100% of inflated amount + 50% penalty |
| Double-Signing | Same counter, different state hashes | Critical | 100% of tx amount + 100% penalty |
| Chain Fork | Two valid-looking branches from same state | High | Higher branch amount + 25% penalty |
| Invalid Signature | Signature doesn't match registered pubkey | High | Transaction rejected, 10% bond penalty |
| Late Settlement | Settlement submitted after deadline | Low | 1% penalty per day late |
6.3.2 Slashing Amounts & Distribution
When slashing occurs, funds are distributed according to a fixed formula:
The fraud reporter reward incentivizes active monitoring of the network. Anyone can submit fraud proofs and claim the reward, creating a decentralized fraud detection ecosystem.
6.3.3 Appeals & Dispute Resolution
Slashing is not immediate—there is a time-locked appeals window:
SLASHING TIMELINE:
T+0h: Fraud detected, slashing initiated
T+0h: Merchant notified, bond frozen
T+0-48h: Appeals window open
• Merchant can submit counter-evidence
• DAO arbitrators review edge cases
T+48h: If no valid appeal, slashing executed
T+48h: Funds distributed to victim/reporter/treasury
VALID APPEAL GROUNDS:
• Terminal malfunction (with hardware logs)
• Network partition (with timestamp evidence)
• Smart contract bug (requires code audit)
6.4 Game-Theoretic Analysis
SCP's security ultimately rests on game theory: fraud must be a losing strategy for rational actors.
6.4.1 Rational Merchant Behavior
Consider a merchant's decision matrix:
| Strategy | Outcome if Undetected | Outcome if Detected | Detection Probability | Expected Value |
|---|---|---|---|---|
| Honest | Normal profit | Normal profit | N/A | +Profit |
| Fraud | Stolen amount | -150% of stolen amount | ~100%* | -50% (loss) |
*Detection probability approaches 100% because fraud requires either (a) breaking the commitment chain (cryptographically infeasible), or (b) never settling (forfeiting all legitimate revenue). Both paths lead to detection.
Honest behavior is the dominant strategy. Regardless of what other merchants do, each individual merchant maximizes their expected value by behaving honestly. This creates a stable equilibrium where fraud is not rational.
6.4.2 Attack Cost vs. Reward
Quantitative analysis of the maximum profitable fraud:
FRAUD ECONOMICS:
Let:
B = Merchant's bonded amount
D = Max card denomination they can accept
S = Slashing penalty multiplier (1.5x for most fraud)
For fraud to be profitable:
Stolen_Amount > B × S
But by design:
B ≥ 2 × D (bond ratio)
Stolen_Amount ≤ D (max card value)
Therefore:
D < 2D × 1.5
D < 3D ✓ (always true)
CONCLUSION: Maximum fraud profit is always less than slashing loss.
6.4.3 Collusion Scenarios
Even collusion attacks are unprofitable:
| Collusion Type | Attack Vector | Mitigation |
|---|---|---|
| Merchant + Cardholder | Inflate balance, split profits | Merchant still loses bond (> inflation amount) |
| Multiple Merchants | Pass inflated card between colluding merchants | Each merchant's signature on chain—all are slashed |
| Merchant + Issuer | Issuer creates cards with fake balances | Issuer bond covers all issued cards; massive slashing |
6.5 Economic Parameters
SCP's economic parameters are carefully tuned to balance security, usability, and capital efficiency.
6.5.1 Minimum Bond Size
The minimum bond formula ensures fraud is always unprofitable:
MINIMUM BOND FORMULA:
min_bond = max_card_denomination × bond_ratio × safety_factor
Where:
bond_ratio = 2.0 (covers fraud + penalty)
safety_factor = 1.0 - 1.25 (buffer for volatility)
EXAMPLE (Bronze):
min_bond = $500 × 2.0 × 1.0 = $1,000
6.5.2 Maximum Card Denomination
Card denominations are capped based on the merchant class to limit risk exposure:
| ECHELON | Max Single Card | Max Daily Volume | Rationale |
|---|---|---|---|
| Bronze | $500 | $10,000 | Covers gift cards, small purchases |
| Silver | $5,000 | $100,000 | Business expenses, mid-value retail |
| Gold | $50,000 | $1,000,000 | High-value goods, B2B payments |
| Platinum | Custom | Unlimited | CBDC, institutional use cases |
6.5.3 Settlement Frequency
Settlement frequency determines the fraud detection window. More frequent settlement = faster fraud detection = lower risk = potentially lower bond requirements:
| ECHELON | Settlement Frequency | Fraud Window | Unbonding Period |
|---|---|---|---|
| Bronze | Daily | 24 hours | 7 days |
| Silver | Twice daily | 12 hours | 14 days |
| Gold | Hourly | 1 hour | 21 days |
| Platinum | Real-time | ~5 seconds | 30 days |
Transaction Flows
SCP supports five transaction types: Issuance (create card), Load (add funds), Payment (spend funds), Settlement (finalize on-chain), and Redemption (withdraw to crypto). Each follows a specific protocol ensuring security and auditability.
7.1 Card Issuance
Card issuance is the process of creating a new SCP card. This involves programming the NTAG 424 DNA chip and registering the card on-chain.
7.1.1 Issuer Registration
Before issuing cards, organizations must register as an approved issuer:
ISSUER REGISTRATION PROCESS:
1. Generate issuer master keypair:
issuer_master = Ed25519_Generate()
issuer_pubkey = Ed25519_PublicKey(issuer_master)
2. Submit registration transaction:
IssuerRegistry.register({
pubkey: issuer_pubkey,
organization: "Acme Payments Inc",
jurisdiction: "US",
echelon_classes: [BRONZE, SILVER],
issuer_bond: 50000 USDC
})
3. KYC verification (for Silver+):
• Business registration documents
• AML compliance attestation
• Insurance certificate (Gold+)
4. Upon approval: issuer_id assigned, can begin minting cards
7.1.2 Card Initialization
Physical card programming involves configuring the NTAG 424 DNA chip:
7.1.3 On-Chain Registration
The final step registers the card in the CardRegistry contract:
CardRegistry.register_card({
card_id: 0x01A2B3C4D5E6F708, // UID-derived
issuer_id: 0x9876543210ABCDEF,
denomination: 500000, // satoshis ($500)
echelon_class: BRONZE,
genesis_hash: 0x7a8b9c..., // Initial state_hash
issued_at: 1704067200 // Unix timestamp
})
// Returns: Card activated, ready for loading
7.2 Card Loading (Top-Up)
Loading adds funds to a card. This can occur through fiat payment, cryptocurrency transfer, or authorized credit.
7.2.1 Fiat On-Ramp
Users can load cards using traditional payment methods:
| Payment Method | Processing Time | Fees | Limits |
|---|---|---|---|
| Debit Card | Instant | 2.9% + $0.30 | $500/day |
| Bank Transfer (ACH) | 1-3 days | 0.5% | $10,000/day |
| Wire Transfer | Same day | $25 flat | Unlimited |
| Cash (at partner locations) | Instant | 1.5% | $500/day |
7.2.2 Crypto On-Ramp
Direct cryptocurrency loading bypasses fiat rails entirely:
CRYPTO LOADING FLOW:
1. User requests load address for card_id
load_address = CardRegistry.get_load_address(card_id)
2. User sends crypto to load_address:
• Stellar (XLM): Native support, ~5 second finality
• Bitcoin: Via atomic swap or bridge, ~60 min
• USDC (Stellar): Stablecoin, instant
3. Smart contract detects deposit:
CardRegistry.process_deposit(card_id, amount)
4. Card balance updated at next physical tap
(or via authorized loading terminal)
7.2.3 Balance Update Protocol
The physical card must be updated to reflect new funds:
BALANCE UPDATE (at loading terminal):
1. READ card SUN message + current state
2. VERIFY SUN CMAC is valid
3. QUERY on-chain pending_balance for card_id
4. COMPUTE new state:
new_balance = current_balance + pending_balance
new_state_hash = SHA256(prev_hash || new_balance || ...)
5. SIGN state transition with loading_terminal_key
6. WRITE new state to card
7. CONFIRM on-chain:
CardRegistry.confirm_load(card_id, new_state_hash)
8. CLEAR pending_balance
Funds sent to a card remain in "pending" state until the physical card is tapped at a loading terminal. This ensures the card's cryptographic state stays synchronized with on-chain records.
7.3 Payment Transaction
Payment is the core transaction type—spending value from a card at a merchant. This flow operates completely offline.
7.3.1 Tap → Read → Verify
7.3.2 State Transition Construction
The terminal constructs the new card state:
function construct_payment(card_state, amount, merchant) {
// Validate
assert(card_state.balance >= amount, "Insufficient funds")
assert(amount <= merchant.max_transaction, "Exceeds limit")
// Compute new state
new_balance = card_state.balance - amount
new_counter = card_state.last_counter + 1
new_state_hash = SHA256(
card_state.state_hash ||
new_balance ||
new_counter ||
merchant.id ||
amount ||
TX_TYPE_DEBIT ||
current_timestamp
)
// Sign
signature = Ed25519_Sign(merchant.privkey, new_state_hash)
return {new_balance, new_state_hash, new_counter, signature}
}
7.3.3 Write → Confirm
The terminal writes the new state back to the card:
WRITE SEQUENCE:
1. Write CURRENT_STATE region (64 bytes):
• balance (8B)
• state_hash (32B)
• last_counter (4B)
• last_merchant (8B)
• last_sig (8B)
• reserved (4B)
2. Append to TRANSACTION_LOG (32 bytes):
• Log entry at circular buffer head
3. Read back and verify:
• Confirm write succeeded
• Verify state_hash matches
4. If verification fails:
• Retry write (up to 3 times)
• If persistent failure, void transaction
7.3.4 Receipt Generation
The terminal generates a customer receipt for verification:
7.4 Settlement
Settlement is the process of submitting offline transactions to the blockchain for finalization, fraud detection, and merchant payment.
7.4.1 Batch Submission
Merchants accumulate transactions locally and submit in batches:
SETTLEMENT BATCH STRUCTURE:
SettlementBatch {
merchant_id: bytes8,
batch_id: uint64,
transactions: [
{
card_id: bytes8,
prev_state_hash: bytes32,
new_state_hash: bytes32,
amount: uint64,
counter: uint32,
timestamp: uint32,
full_signature: bytes64
},
// ... more transactions
],
batch_signature: bytes64 // Signs entire batch
}
7.4.2 Chain Validation
The settlement contract validates each transaction in the batch:
FOR each transaction IN batch:
// 1. Verify signature
ASSERT Ed25519_Verify(merchant.pubkey, tx, tx.signature)
// 2. Verify state chain
known_hash = CardRegistry.get_state_hash(tx.card_id)
ASSERT tx.prev_state_hash == known_hash
// 3. Verify counter progression
known_counter = CardRegistry.get_counter(tx.card_id)
ASSERT tx.counter > known_counter
// 4. Recompute and verify state hash
computed_hash = compute_state_hash(tx)
ASSERT computed_hash == tx.new_state_hash
// 5. Update on-chain state
CardRegistry.update_state(tx.card_id, tx.new_state_hash, tx.counter)
7.4.3 Merchant Credit
Upon successful validation, merchants are credited:
| Component | Amount | Recipient |
|---|---|---|
| Transaction Amount | 100% | Merchant |
| Protocol Fee | -0.3% | Treasury |
| Network Fee | -~$0.0001 | Stellar validators |
| Net to Merchant | ~99.7% | Merchant wallet |
7.4.4 Fraud Detection Trigger
If validation fails, the fraud detection engine is triggered:
FRAUD DETECTION TRIGGERS:
• Signature invalid → SLASH(merchant, INVALID_SIG)
• State hash mismatch → INVESTIGATE(card_id, merchant)
• Counter regression → SLASH(merchant, COUNTER_FRAUD)
• Duplicate submission → REJECT (no slash, just ignore)
• Balance overflow → SLASH(merchant, BALANCE_INFLATION)
INVESTIGATION PROCESS:
1. Freeze merchant bond
2. Query all merchants who touched card_id
3. Identify fork point in commitment chain
4. Attribute fraud to signing merchant
5. Execute slashing after appeal window
7.5 Card Redemption
Redemption converts card balance back to cryptocurrency, either partially or completely.
7.5.1 Full Redemption
Complete withdrawal of all funds and card deactivation:
FULL REDEMPTION FLOW:
1. User taps card at redemption terminal
2. Terminal verifies card state and balance
3. User provides destination wallet address
4. Terminal creates redemption transaction:
• new_balance = 0
• tx_type = REDEMPTION
5. Card state updated (balance = 0)
6. Settlement submitted immediately
7. On-chain: Funds sent to destination wallet
8. Card status set to REDEEMED (can be reloaded later)
7.5.2 Partial Withdrawal
Withdraw a portion while keeping the card active:
PARTIAL WITHDRAWAL:
// Same as full redemption, but:
new_balance = current_balance - withdrawal_amount
tx_type = PARTIAL_REDEMPTION
// Card remains active with reduced balance
// Minimum balance of $1 required to keep card active
7.5.3 Card Decommissioning
Permanent card retirement (lost, damaged, or expired cards):
DECOMMISSION PROCESS:
1. Issuer or cardholder initiates decommission request
2. If balance > 0:
• Funds sent to registered recovery address
• OR held in escrow for claim period (90 days)
3. Card status set to DECOMMISSIONED
4. card_id added to permanent blocklist
5. Terminals reject all future transactions
NOTE: Physical card should be destroyed to prevent confusion
Security Analysis
SCP assumes adversaries are well-funded, technically sophisticated, and economically rational. Security relies on making attacks cryptographically impossible, economically unprofitable, or detectable with certainty.
8.1 Threat Model
8.1.1 Adversary Capabilities
SCP is designed to resist adversaries with the following capabilities:
| Capability | Description | Assumed? |
|---|---|---|
| Read NFC | Intercept all NFC communications | ✓ Yes |
| Write NFC | Modify card memory contents | ✓ Yes |
| Clone Cards | Duplicate data to another NFC tag | ✓ Yes (data only) |
| Control Terminal | Run malicious merchant software | ✓ Yes |
| Network MITM | Intercept/modify network traffic | ✓ Yes |
| Collude | Coordinate with other attackers | ✓ Yes |
| Break NTAG Silicon | Extract keys from chip hardware | ✗ No |
| Break Cryptography | Find collisions in SHA-256, forge Ed25519 | ✗ No |
| Control Blockchain | 51% attack on Stellar network | ✗ No |
8.1.2 Trust Assumptions
SCP's security rests on the following assumptions:
NXP's tamper-resistant design prevents key extraction. Counter cannot be decremented. CMAC is unforgeable without SDM key.
AES-128, SHA-256, Ed25519 are secure. No practical attacks exist against these algorithms at current security levels.
Stellar network operates correctly. Finalized transactions cannot be reversed. Smart contracts execute as written.
Attackers prefer profit over loss. Given a choice between honest operation and unprofitable fraud, they choose honesty.
8.2 Attack Vectors & Mitigations
8.2.1 Card Cloning → SUN Authentication
Attacker reads all card memory and writes it to a blank NTAG 424. They attempt to spend from both the original and clone.
SUN CMAC includes the chip's UID. Clone has different UID → CMAC verification fails. Attack detected immediately at terminal.
WHY CLONING FAILS:
Original card: UID = 0x04A1B2C3D4E5F6
Clone card: UID = 0x04F6E5D4C3B2A1 (different)
CMAC_original = AES-CMAC(SDM_key, 0x04A1B2C3D4E5F6 || counter || ...)
CMAC_clone = AES-CMAC(SDM_key, 0x04F6E5D4C3B2A1 || counter || ...)
CMAC_original ≠ CMAC_clone (different UIDs)
Terminal expects CMAC computed with clone's UID → MISMATCH → REJECTED
8.2.2 Balance Inflation → Merchant Signatures + Slashing
Malicious merchant writes a higher balance to the card without receiving actual payment. They profit from the inflated value.
Every state change requires merchant signature. Settlement layer detects inflation (balance increased without credit tx). Merchant's bond is slashed.
Economic analysis: If merchant inflates a $500 card, they gain at most $500. But slashing costs them $750+ (150% of fraud amount from their $1000+ bond). Net loss: $250+. Fraud is unprofitable.
8.2.3 State Rollback → Hardware Counter
Cardholder backs up card state (balance $100), spends $50, then restores the backup to regain the $50.
Hardware counter increments with each tap. Cannot be decremented. Restored backup shows counter=N but chip shows counter=N+1. Mismatch detected.
ROLLBACK DETECTION:
T0: Backup state {balance: 100, counter: 42, state_hash: H42}
T1: Spend $50 {balance: 50, counter: 43, state_hash: H43}
T2: Restore backup {balance: 100, counter: 42, state_hash: H42}
BUT: Hardware counter is now 43 (cannot be rolled back)
Terminal reads:
• Memory shows counter=42 (from restored backup)
• SUN message contains counter=43 (from hardware)
• MISMATCH → Rollback detected → Card rejected
8.2.4 Double Spending → Transaction Log + Settlement
Cardholder spends at Merchant A, then quickly spends again at Merchant B before either settles.
This is normal operation, not an attack! Card balance decreases with each spend. Each transaction is valid and both will settle.
True double-spend attempt (spending same funds twice) requires state manipulation, which triggers the mitigations above (rollback detection, chain validation).
8.2.5 Merchant Collusion → Bond Requirements
Multiple merchants conspire. Merchant A inflates card, passes to Merchant B who spends it, they split the profits.
Every state transition has a merchant signature. Commitment chain reveals who inflated the balance. All colluding merchants are slashed.
Economic analysis: Each merchant must post a full bond. If 3 merchants collude to inflate $500, they gain $500 total but lose 3 × $1000 = $3000 in slashed bonds. Collusion amplifies losses, not gains.
8.2.6 Replay Attacks → Counter Binding
Attacker records a valid SUN message and replays it to make fraudulent transactions.
SUN CMAC includes counter value. Each tap increments counter. Replayed message has old counter → rejected. Counter never repeats.
8.3 Failure Modes
8.3.1 Card Destruction Mid-Transaction
Scenario: Card is removed from NFC field during write operation, corrupting state.
RECOVERY PROCEDURE:
1. Terminal detects write failure (read-back mismatch)
2. Transaction marked as "pending verification"
3. Customer retaps card:
a. If state matches expected → Transaction complete
b. If state is old → Retry write
c. If state is corrupted → Card flagged for replacement
4. Corrupted cards can be replaced by issuer
5. On-chain balance preserved; new card issued with same balance
8.3.2 Terminal Failure
Scenario: Terminal crashes after writing to card but before saving transaction locally.
RECOVERY PROCEDURE:
1. Card state is updated (customer has new balance)
2. Terminal transaction log is lost
3. Next merchant to accept card sees valid state
4. Original merchant cannot claim funds (no proof)
MERCHANT IMPACT: Merchant loses the transaction amount
CUSTOMER IMPACT: None (balance correctly debited)
SYSTEM IMPACT: None (no inflation, no fraud)
PREVENTION: Transaction-safe storage, battery backup, UPS
8.3.3 Network Partition
Scenario: Merchant cannot connect to settlement layer for extended period.
HANDLING:
1. Offline operation continues normally
2. Transactions queue locally (days/weeks if needed)
3. When connectivity restored, batch settlement submitted
4. Fraud window extends (higher risk for merchant)
RISK: Cards could be double-spent across partitioned merchants
MITIGATION:
• Transaction limits during extended offline
• Merchant assumes fraud risk during partition
• Insurance for extended offline scenarios
8.4 Formal Security Properties
8.4.1 Unforgeability
Property: No probabilistic polynomial-time (PPT) adversary can produce a valid state transition without the corresponding merchant private key.
FORMAL STATEMENT:
∀ PPT adversary A:
Pr[A produces valid (state_transition, signature)
without knowing merchant_privkey] ≤ negl(λ)
Where negl(λ) is negligible in security parameter λ.
PROOF SKETCH: Reduces to unforgeability of Ed25519 under
the Discrete Logarithm assumption in the elliptic curve group.
8.4.2 Non-Repudiation
Property: A merchant cannot deny authorizing a transaction once the signature is verified on-chain.
FORMAL STATEMENT:
∀ merchant M with registered pubkey pk_M:
If Ed25519_Verify(pk_M, tx, sig) = TRUE
Then M authorized tx (or M's key was compromised)
Key compromise is merchant's responsibility (bond at risk).
8.4.3 Fraud Detectability
Property: Any deviation from the protocol is detectable with probability 1 upon settlement.
FORMAL STATEMENT:
∀ fraudulent transaction tx_fraud:
Pr[Settlement_Verify(tx_fraud) = VALID] = 0
PROOF: Fraud requires one of:
1. Breaking commitment chain → requires SHA-256 collision
2. Forging signature → requires breaking Ed25519
3. Manipulating counter → requires breaking NTAG silicon
4. Valid fraud (signed by merchant) → detected and slashed
Cases 1-3 violate trust assumptions. Case 4 is detected.
ECHELON Class System
ECHELON is SCP's tiered classification system that matches security requirements to use case needs. Higher classes provide greater transaction limits and faster settlement, balanced by stricter merchant requirements and larger bonds.
9.1 Class Definitions
9.1.1 ECHELON Bronze (Consumer)
9.1.2 ECHELON Silver (Business)
9.1.3 ECHELON Gold (Enterprise)
9.1.4 ECHELON Platinum (Government/CBDC)
9.2 Feature Matrix
| Feature | Bronze | Silver | Gold | Platinum |
|---|---|---|---|---|
| Max Card Value | $500 | $5,000 | $50,000 | Unlimited |
| Min Merchant Bond | $1,000 | $10,000 | $100,000 | $1,000,000 |
| Settlement Frequency | Daily | 12 hours | Hourly | Real-time |
| Max Daily Volume | $10,000 | $100,000 | $1,000,000 | Unlimited |
| Unbonding Period | 7 days | 14 days | 21 days | 30 days |
| Merchant KYC | None | Basic ID | Enhanced | Full + AML |
| Cardholder KYC | None | None | Optional | Configurable |
| Key Storage | Encrypted file | TEE/Enclave | HSM required | FIPS 140-3 |
| Audit Requirements | None | Annual | Quarterly | Continuous |
| Insurance Required | No | No | Recommended | Required |
| SLA Guarantee | None | 99% | 99.9% | 99.99% |
| Support Level | Community | Priority | Dedicated |
9.3 Bond Requirements by Class
Bond requirements are calculated to ensure fraud is always unprofitable:
BOND CALCULATION FORMULA:
minimum_bond = max_card_denomination × bond_multiplier
Where bond_multiplier by class:
• Bronze: 2.0x ($500 × 2.0 = $1,000)
• Silver: 2.0x ($5,000 × 2.0 = $10,000)
• Gold: 2.0x ($50,000 × 2.0 = $100,000)
• Platinum: 2.0x+ (negotiated based on volume)
ADDITIONAL REQUIREMENTS:
• Volume-based: +10% bond per $1M monthly volume
• Multi-location: +$1,000 per additional terminal
• New merchants: 1.5x bond for first 6 months
9.4 Transaction Limits
Transaction limits provide additional fraud protection through velocity controls:
| Limit Type | Bronze | Silver | Gold | Platinum |
|---|---|---|---|---|
| Single Transaction | $500 | $5,000 | $50,000 | Custom |
| Per Card Daily | $1,000 | $10,000 | $100,000 | Custom |
| Merchant Daily | $10,000 | $100,000 | $1,000,000 | Unlimited |
| Tx per Card/Hour | 10 | 20 | 50 | Unlimited |
| New Card Cooldown | 24 hours | 12 hours | 1 hour | None |
9.5 Settlement Priorities
Higher ECHELON classes receive priority processing during high-volume periods:
SETTLEMENT QUEUE PRIORITY:
Priority 1 (Highest): Platinum transactions
• Real-time processing
• Dedicated validator nodes
• Guaranteed <5 second finality
Priority 2: Gold transactions
• Hourly batch processing
• Priority queue position
• Target <10 minute finality
Priority 3: Silver transactions
• Twice-daily batch processing
• Standard queue position
• Target <12 hour finality
Priority 4 (Lowest): Bronze transactions
• Daily batch processing
• Best-effort queue position
• Target <24 hour finality
During network congestion, lower priority transactions may be
delayed, but are never dropped. All valid transactions settle.
Implementation Specifications
SCP has a working MVP implementation. This section documents the technical specifications used in the current deployment, enabling third-party implementations and interoperability.
10.1 Card Programming
10.1.1 NTAG 424 DNA Configuration
NTAG 424 DNA chips must be configured with specific settings for SCP operation:
NTAG 424 DNA CONFIGURATION:
// File Settings
File 01 (CC File): Default (Capability Container)
File 02 (NDEF File): 256 bytes, SUN message enabled
File 03 (Prop File): 416 bytes (SCP card data)
// Key Configuration
Key Slot 0x00: Card master key (AES-128, set by issuer)
Key Slot 0x01: Reserved
Key Slot 0x02: SDM key (AES-128, derived per-card)
Key Slot 0x03: Read/Write key for File 03
Key Slot 0x04: Reserved
// Access Conditions
File 02 Read: Free access (for SUN URL)
File 02 Write: Key 0x00 required
File 03 Read: Free access (terminals can read state)
File 03 Write: Key 0x03 required (merchants can update)
// SUN Configuration
SDM Enabled: Yes
SDM Access Rights: Key 0x02
UID Mirroring: Enabled (7 bytes)
Counter Mirroring: Enabled (3 bytes)
CMAC Output: 8 bytes (truncated)
10.1.2 Memory Mapping
Detailed byte-level mapping of the 416-byte data file:
10.1.3 Access Conditions
File 03 access conditions define read/write permissions:
| Region | Read Access | Write Access | Rationale |
|---|---|---|---|
| Header (0x00-0x1F) | Free | Locked | Immutable after issuance |
| State (0x20-0x5F) | Free | Key 0x03 | Merchants update with key |
| Log (0x60-0x19F) | Free | Key 0x03 | Merchants append entries |
10.2 Terminal Software
10.2.1 NFC Reader Requirements
| Requirement | Specification | Notes |
|---|---|---|
| Protocol | ISO 14443-A | Required for NTAG 424 |
| Frequency | 13.56 MHz | NFC standard |
| APDU Support | Extended APDU | For 416-byte reads |
| Data Rate | ≥424 kbps | For sub-500ms transactions |
| Field Strength | 1.5-7.5 A/m | Per ISO 14443 |
| Read Range | ≥3 cm | Practical tap distance |
10.2.2 Reference Implementation
The reference terminal implementation is available in multiple languages:
• NFC via pcsc crate
• Async settlement
• MIT Licensed
• pyscard for NFC
• Interactive CLI
• MIT Licensed
• Android NFC API
• Material UI
• Apache 2.0 Licensed
REPOSITORY STRUCTURE:
scp-terminal/
├── rust/ # Production terminal
│ ├── src/
│ │ ├── nfc.rs # NFC communication
│ │ ├── crypto.rs # Ed25519, SHA256, CMAC
│ │ ├── state.rs # Card state management
│ │ ├── settle.rs # Settlement client
│ │ └── main.rs
│ └── Cargo.toml
├── python/ # Testing tools
├── android/ # Mobile app
└── docs/ # API documentation
10.2.3 SDK & APIs
Terminal SDK provides high-level APIs for common operations:
// RUST SDK EXAMPLE
use scp_terminal::{Terminal, Card, Transaction};
// Initialize terminal with merchant credentials
let terminal = Terminal::new(
merchant_id,
merchant_privkey,
echelon_class,
)?;
// Process payment (single function call)
let result = terminal.process_payment(
amount_sats, // Payment amount
timeout_ms, // Max wait for tap
).await?;
match result {
PaymentResult::Success(receipt) => {
println!("Payment complete: {}", receipt.tx_id);
}
PaymentResult::InsufficientFunds(balance) => {
println!("Card balance: {} sats", balance);
}
PaymentResult::InvalidCard(reason) => {
println!("Card rejected: {}", reason);
}
}
10.3 Smart Contracts
10.3.1 Soroban Contract Architecture
SCP uses three primary Soroban smart contracts on Stellar:
• State tracking
• Balance queries
• Revocation list
• Withdrawal requests
• Slashing logic
• Yield distribution
• Chain validation
• Fraud detection
• Payment routing
10.3.2 Contract Interfaces
// SOROBAN CONTRACT INTERFACES (Rust)
// CardRegistry Contract
pub trait CardRegistryTrait {
fn register_card(env: Env, card: CardInfo) -> Result<(), Error>;
fn get_card_state(env: Env, card_id: BytesN<8>) -> CardState;
fn update_state(env: Env, card_id: BytesN<8>,
new_hash: BytesN<32>, counter: u32) -> Result<(), Error>;
fn revoke_card(env: Env, card_id: BytesN<8>, reason: Symbol) -> Result<(), Error>;
}
// MerchantBond Contract
pub trait MerchantBondTrait {
fn register(env: Env, pubkey: BytesN<32>, class: u8) -> Result<(), Error>;
fn deposit(env: Env, merchant_id: BytesN<8>, amount: i128) -> Result<(), Error>;
fn request_withdrawal(env: Env, merchant_id: BytesN<8>,
amount: i128) -> Result<(), Error>;
fn slash(env: Env, merchant_id: BytesN<8>,
amount: i128, evidence: Bytes) -> Result<(), Error>;
}
// Settlement Contract
pub trait SettlementTrait {
fn submit_batch(env: Env, batch: SettlementBatch) -> Result<BatchResult, Error>;
fn get_batch_status(env: Env, batch_id: u64) -> BatchStatus;
fn report_fraud(env: Env, proof: FraudProof) -> Result<(), Error>;
}
10.3.3 Deployment Guide
# SOROBAN DEPLOYMENT
# 1. Install Soroban CLI
cargo install soroban-cli
# 2. Configure network
soroban config network add testnet \
--rpc-url https://soroban-testnet.stellar.org \
--network-passphrase "Test SDF Network ; September 2015"
# 3. Build contracts
cd contracts/
soroban contract build
# 4. Deploy CardRegistry
soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/card_registry.wasm \
--network testnet \
--source deployer
# 5. Initialize contract
soroban contract invoke \
--id <CONTRACT_ID> \
--network testnet \
--source admin \
-- initialize --admin <ADMIN_PUBKEY>
10.4 Reference Hardware
10.4.1 Recommended NFC Readers
| Reader | Interface | Price | Use Case | Status |
|---|---|---|---|---|
| ACR1252U | USB | ~$40 | Development, Desktop POS | ✓ Tested |
| ACR122U | USB | ~$30 | Budget development | ✓ Tested |
| HID Omnikey 5427 | USB | ~$100 | Enterprise, high reliability | ✓ Tested |
| Android NFC | Built-in | N/A | Mobile terminals | ✓ Tested |
| PN532 Module | I2C/SPI | ~$10 | Embedded, Raspberry Pi | ⚠ Experimental |
10.4.2 Card Suppliers
NTAG 424 DNA cards are available from multiple manufacturers:
| Supplier | MOQ | Unit Price | Custom Print | Lead Time |
|---|---|---|---|---|
| NXP Direct | 10,000 | $0.80-1.20 | ✓ | 4-6 weeks |
| Identiv | 1,000 | $1.00-1.50 | ✓ | 2-4 weeks |
| Alibaba (various) | 100 | $1.20-2.00 | ✓ | 2-3 weeks |
| Amazon (samples) | 5 | $3.00-5.00 | ✗ | 1-2 days |
Counterfeit NTAG 424 DNA chips exist in the market. Always verify authenticity using NXP's TagInfo app. Genuine chips will show "Originality Signature: VALID". Source only from authorized distributors for production.
10.4.3 HSM Options
Hardware Security Modules for merchant key protection:
| HSM Option | Type | Price | ECHELON Class |
|---|---|---|---|
| AWS CloudHSM | Cloud | $1.50/hr | Silver, Gold |
| Azure Dedicated HSM | Cloud | ~$5,000/mo | Gold, Platinum |
| YubiHSM 2 | Physical (USB) | $650 | Silver, Gold |
| Thales Luna Network HSM | Physical (Network) | $20,000+ | Gold, Platinum |
| Utimaco SecurityServer | Physical (Network) | $15,000+ | Gold, Platinum |
Use Cases
SCP addresses real-world payment challenges across multiple verticals. Each use case leverages SCP's unique combination of offline operation, cryptocurrency settlement, and low hardware costs.
11.1 Remittances & Unbanked Populations
Problem: Migrant workers sending money home face high fees (often 7-10% to Africa), slow transfers (3-5 days), and recipients need bank accounts or must travel to agent locations.
SCP Solution: Worker loads SCP card with crypto, physically mails card to family. Recipient spends at local merchants or redeems to mobile money. Total cost: card ($2) + postage ($2) + 0.3% fee = ~$5 flat regardless of amount.
Example Flow:
- Worker in USA buys $500 Bronze card, loads via Coinbase
- Mails card to family in Philippines (5-7 days)
- Family spends at participating sari-sari stores
- Or redeems to GCash/Maya mobile wallet
| Corridor | Traditional Fee | SCP Fee | Savings on $500 |
|---|---|---|---|
| USA → Mexico | 4.5% | ~1% | $17.50 |
| USA → Philippines | 5.2% | ~1% | $21.00 |
| UK → Nigeria | 8.5% | ~1% | $37.50 |
| UAE → India | 3.8% | ~1% | $14.00 |
11.2 Transit Systems
Problem: Transit agencies use proprietary closed-loop cards (Oyster, Clipper, OMNY) that cost $8-15 each, don't interoperate, and create vendor lock-in.
SCP Solution: Open-standard transit cards at $2 each. Interoperable across any SCP-enabled transit system worldwide. Tourists can use the same card in London, Tokyo, and New York.
Benefits:
- 80% hardware cost reduction
- No vendor lock-in
- Real-time settlement to transit authority
- Interoperability with retail (coffee at station)
11.3 Event & Venue Payments
Problem: Large events (festivals, stadiums, conferences) struggle with payments—cash is slow, card terminals need connectivity, and proprietary wristband systems are expensive.
SCP Solution:
11.4 Gift Cards & Loyalty Programs
Problem: Traditional gift cards are fraud-prone (balance theft, card draining), single-merchant, and centralized.
SCP Solution: Crypto-backed physical gift cards that work at any SCP merchant. Self-custody, fraud-resistant, and optionally privacy-preserving.
Product Options:
- Open-loop: Spendable anywhere (like Visa gift cards)
- Branded: Custom designs for retail chains
- Corporate: Employee rewards, bulk purchasing
- Cross-merchant loyalty: Points redeemable across network
11.5 CBDC Infrastructure
The CBDC Offline Challenge: Over 130 countries are actively exploring or piloting CBDCs, yet the offline payment challenge remains largely unsolved. Digital currencies require digital infrastructure—which billions still lack.
SCP as CBDC Distribution Layer:
- Platinum-class cards issued by central banks
- CBDC tokens stored on physical cards
- Offline transactions between citizens
- Full auditability for central bank
- Integration with existing Stellar/Soroban CBDC pilots
Pilot Partners: In discussions with central banks in 3 emerging market countries (NDAs in place).
11.6 Humanitarian Aid Distribution
Scenario: Hurricane destroys cellular infrastructure. Traditional payment systems are down. Cash is scarce.
SCP Response:
- Relief organization airdrops pre-loaded SCP cards to affected population
- Local merchants (even with no connectivity) accept cards via battery-powered terminals
- Transactions accumulate offline for days/weeks if needed
- When connectivity restored, batch settlement processes all transactions
- Full audit trail shows exactly how relief funds were spent
Benefits for NGOs:
- Reduced leakage and corruption
- Transparent reporting to donors
- Dignity for recipients (cards, not handouts)
- Works where mobile money doesn't
11.7 Gaming & Micropayments
SCP enables physical micropayment tokens for gaming and entertainment:
| Use Case | Traditional Method | SCP Advantage |
|---|---|---|
| Arcade Tokens | Metal tokens, proprietary systems | Universal cards, cross-venue |
| Casino Chips | Expensive custom chips, fraud risk | Cryptographically secure, auditable |
| Gaming Cards | Paper cards, easy to counterfeit | NFC verification, impossible to clone |
| Vending Micropayments | Coins, card fees too high | Sub-cent fees, instant settlement |
Regulatory Considerations
This section provides general guidance only and does not constitute legal advice. SCP operators should consult qualified legal counsel in their operating jurisdictions. Regulatory landscapes are evolving rapidly in the cryptocurrency and payments space.
12.1 Money Transmission Laws
SCP's regulatory classification varies by jurisdiction and the specific role an entity plays in the ecosystem:
| Role | US Classification | EU Classification | Likely License Required |
|---|---|---|---|
| Card Issuer | Money Transmitter | E-Money Institution | Yes |
| Merchant | None (accepts payment) | None (accepts payment) | No |
| Protocol Operator | Potentially MSB | Varies | Depends on role |
| Settlement Provider | Money Transmitter | Payment Institution | Yes |
US STATE-BY-STATE CONSIDERATIONS:
• 49 states + DC require money transmitter licenses
• Montana is the only state without MTL requirement
• Processing time: 3-12 months per state
• Cost: $5,000-$500,000 per state (bonding + fees)
• Nationwide licensing via NMLS streamlined process
POTENTIAL EXEMPTIONS TO ANALYZE:
• Payment processor exemption (some states)
• Agent of licensed entity exemption
• Bank partnership model
• Prepaid access exemption (FinCEN)
12.2 KYC/AML Compliance
SCP implements tiered KYC based on ECHELON class and risk profile:
| ECHELON | Cardholder KYC | Merchant KYC | Transaction Monitoring |
|---|---|---|---|
| Bronze | None (under thresholds) | None | Velocity checks only |
| Silver | None | Basic ID + Business verification | Pattern analysis |
| Gold | Optional (issuer discretion) | Enhanced due diligence | Full AML monitoring |
| Platinum | Per central bank requirements | Full KYC + ongoing monitoring | Real-time + reporting |
- Transaction limits: Enforced at card level (no single card exceeds denomination)
- Velocity limits: Per-card daily/monthly limits prevent structuring
- Merchant monitoring: Unusual patterns trigger review
- Sanctions screening: OFAC/EU sanctions list for Silver+ merchants
- SAR filing: Suspicious Activity Reports for qualifying transactions
12.3 Consumer Protection
SCP incorporates consumer protection measures aligned with prepaid card regulations:
| Protection | SCP Implementation | Regulatory Alignment |
|---|---|---|
| Lost/Stolen Cards | Card revocation + balance recovery to registered address | Reg E (limited liability) |
| Unauthorized Transactions | Cryptographic proof of authorization required | EFTA protections |
| Balance Disclosure | Balance visible on every transaction receipt | CFPB prepaid rule |
| Fee Disclosure | All fees disclosed before card purchase | TILA requirements |
| Expiration | No expiration on card value | CARD Act compliant |
| Inactivity Fees | No inactivity fees | CARD Act compliant |
12.4 Cross-Border Considerations
SCP's physical card nature creates unique cross-border regulatory considerations:
CROSS-BORDER USAGE SCENARIOS:
1. CARD ISSUED IN COUNTRY A, USED IN COUNTRY B
• Card follows issuer's regulatory framework
• Merchant follows local payment acceptance rules
• Settlement occurs on Stellar (borderless)
2. REMITTANCE (CARD MAILED INTERNATIONALLY)
• May trigger customs declaration requirements
• Value reporting thresholds vary by country
• Not subject to wire transfer regulations (physical transfer)
3. SANCTIONS COMPLIANCE
• Cards cannot be issued to sanctioned individuals/entities
• Merchants in sanctioned jurisdictions cannot be onboarded
• Settlement contracts include sanctions screening hooks
12.5 CBDC Regulatory Frameworks
SCP as CBDC Infrastructure: When deployed as a CBDC distribution mechanism, SCP operates under the central bank's regulatory authority. Key considerations:
- Issuance authority: Only central bank (or authorized agents) can issue Platinum cards
- Monetary policy: Card denominations tied to national currency
- Privacy balance: Configurable per jurisdiction's requirements
- Interoperability: Cross-border CBDC settlements via Stellar bridges
- Programmability: Smart contract restrictions per government policy
Roadmap
SCP has a working MVP implementation with functional cards, terminals, and smart contracts. The roadmap below outlines the path from current state to full production deployment.
13.1 Phase 1: MVP (Complete)
13.2 Phase 2: Pilot Deployment (Q1-Q2 2026) — In Progress
13.3 Phase 3: Mainnet Launch (Q3-Q4 2026)
13.4 Phase 4: Enterprise & CBDC (2027+)
Conclusion
14.1 Summary of Contributions
The Sovereign Cash Protocol represents a fundamental breakthrough in bringing cryptocurrency to the physical world. Key contributions include:
First application of PoS-inspired bonding/slashing to physical payment systems. Fraud becomes economically irrational without expensive hardware.
Novel cryptographic construction linking physical card state to blockchain settlement. Provides tamper-evidence and fraud attribution.
Complete transactions without any network connectivity. No other crypto payment system achieves this with stored-value cards.
Sub-$2 card cost enables mass-market deployment. 10x cheaper than existing crypto card solutions while providing stronger security guarantees.
14.2 Open Research Questions
Several areas warrant further investigation:
OPEN RESEARCH QUESTIONS:
1. FORMAL VERIFICATION
• Machine-checkable proofs of security properties
• Smart contract formal verification
• Protocol correctness proofs in Coq/Lean
2. PRIVACY ENHANCEMENTS
• Zero-knowledge proofs for balance verification
• Unlinkable transactions while maintaining auditability
• Merchant privacy (hide transaction volumes)
3. SCALABILITY
• Layer 2 settlement aggregation
• Cross-chain settlement for non-Stellar assets
• Hierarchical merchant networks
4. ALTERNATIVE HARDWARE
• Next-generation NFC chips (post-NTAG 424)
• Secure element integration options
• Wearable form factors (rings, watches)
14.3 Call to Action
SCP is an open ecosystem. We invite participation from:
Glossary of Terms
| Term | Definition |
|---|---|
| AES-128-CMAC | Cipher-based Message Authentication Code using 128-bit AES. Used by NTAG 424 DNA for SUN authentication. |
| Bearer Instrument | A financial instrument where possession equals ownership. Physical holder can spend the value without additional authentication. |
| Bonding | The act of depositing collateral into a smart contract as a guarantee of honest behavior. |
| Commitment Chain | A cryptographic hash chain linking successive card states, providing tamper-evidence and fraud attribution. |
| ECHELON | SCP's tiered classification system (Bronze, Silver, Gold, Platinum) matching security requirements to use case needs. |
| Ed25519 | Edwards-curve Digital Signature Algorithm. Used for merchant transaction signatures. |
| HKDF | HMAC-based Key Derivation Function. Used to derive card-specific keys from issuer master key. |
| HSM | Hardware Security Module. Tamper-resistant device for cryptographic key storage. |
| NTAG 424 DNA | NXP's advanced NFC chip with AES-128 cryptography, hardware counter, and Secure Unique NFC (SUN) messaging. |
| SDM Key | Secure Dynamic Messaging key programmed into NTAG 424 for CMAC generation. |
| Settlement | The process of submitting offline transactions to the blockchain for validation and finalization. |
| Slashing | Automatic penalty (bond reduction) applied when fraud is cryptographically proven. |
| Soroban | Stellar's smart contract platform. Hosts SCP's CardRegistry, MerchantBond, and Settlement contracts. |
| SUN | Secure Unique NFC. NTAG 424's authentication protocol that generates unique CMACs per tap. |
| UID | Unique Identifier. 7-byte factory-programmed identifier in each NTAG chip, cannot be modified. |
Mathematical Proofs
B.1 Fraud Unprofitability Theorem
THEOREM: Under SCP parameters, fraud is always unprofitable for rational merchants.
PROOF:
Let:
D = Maximum card denomination for merchant's ECHELON class
B = Merchant's bonded amount
P = Slashing penalty multiplier (1.5 for most fraud types)
R = Bond ratio (2.0 by protocol requirement)
By protocol design: B ≥ R × D = 2D
Maximum fraud profit: F_max = D (inflate card to max denomination)
Fraud cost if detected: C = B × P = 2D × 1.5 = 3D
Detection probability: p → 1 (approaches certainty)
• Commitment chain makes fraud cryptographically verifiable
• Settlement is mandatory for merchant payment
• Fraud visible on-chain with 100% certainty
Expected value of fraud: E[fraud] = (1-p) × F_max - p × C
As p → 1: E[fraud] → -C = -3D
Expected value of honesty: E[honest] = normal_profit > 0
Since E[fraud] < 0 < E[honest], rational merchants choose honesty. ∎
B.2 Commitment Chain Collision Resistance
THEOREM: Finding two different transaction histories that produce the same
state_hash requires breaking SHA-256 collision resistance.
PROOF:
state_hash[n] = SHA256(state_hash[n-1] || balance || counter || ...)
For two histories H and H' to collide at state n:
state_hash[n] in H = state_hash[n] in H'
This requires either:
(a) state_hash[n-1] identical AND all tx[n] fields identical → Same history
(b) Different inputs producing same SHA-256 output → Collision
SHA-256 collision resistance: 2^128 operations (birthday bound)
Therefore, forging an alternative history requires 2^128 operations,
which is computationally infeasible. ∎
Smart Contract Source Code
Core contract interfaces (simplified for readability). Full source available at GitHub.
// CardRegistry.rs - Soroban Smart Contract
#![no_std]
use soroban_sdk::{contract, contractimpl, Env, BytesN, Symbol};
#[derive(Clone)]
pub struct CardInfo {
pub card_id: BytesN<8>,
pub issuer_id: BytesN<8>,
pub denomination: u64,
pub echelon_class: u8,
pub genesis_hash: BytesN<32>,
pub issued_at: u64,
pub status: u8,
}
#[contract]
pub struct CardRegistry;
#[contractimpl]
impl CardRegistry {
pub fn register(env: Env, card: CardInfo) -> Result<(), Error> {
// Verify issuer is authorized
// Store card info
// Emit registration event
}
pub fn update_state(
env: Env,
card_id: BytesN<8>,
new_hash: BytesN<32>,
counter: u32
) -> Result<(), Error> {
// Verify caller is authorized merchant
// Verify counter progression
// Update state hash
}
pub fn get_state(env: Env, card_id: BytesN<8>) -> CardState {
// Return current on-chain state
}
}
Card Data Structure Reference
D.1 Test Vectors
TEST VECTOR 1: Genesis State
card_id: 0x01A2B3C4D5E6F708
issuer_id: 0x9876543210ABCDEF
denomination: 500000 (0x0007A120)
issued_at: 1704067200 (0x6592A380)
echelon_class: 0x01 (BRONZE)
version: 0x01
initial_balance: 0 (0x0000000000000000)
genesis_hash: SHA256("SCP-GENESIS" || card_id || issuer_id)
= 0x7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d...
TEST VECTOR 2: After First Transaction
Transaction: -12500 sats ($12.50 payment)
prev_balance: 500000
new_balance: 487500 (0x0000000000077064)
counter: 1
merchant_id: 0xFEDCBA9876543210
new_state_hash = SHA256(
genesis_hash ||
0x0000000000077064 || // new_balance
0x00000001 || // counter
0xFEDCBA9876543210 || // merchant_id
0x0000000000003044 || // amount (12500)
0x02 || // TX_TYPE_DEBIT
0x6592A400 // timestamp
)
API Specifications
E.1 Settlement API
POST /api/v1/settlement/batch
Request:
{
"merchant_id": "0xFEDCBA9876543210",
"batch_id": 12345,
"transactions": [
{
"card_id": "0x01A2B3C4D5E6F708",
"prev_state_hash": "0x7a8b9c...",
"new_state_hash": "0x1d2e3f...",
"amount": 12500,
"counter": 1,
"timestamp": 1704067584,
"signature": "0xabc123..."
}
],
"batch_signature": "0xdef456..."
}
Response (200 OK):
{
"batch_id": 12345,
"status": "ACCEPTED",
"transactions_processed": 1,
"total_amount": 12500,
"net_credit": 12462, // after 0.3% fee
"stellar_tx_hash": "0x789abc..."
}
Security Audit Checklist
| Category | Check | Priority |
|---|---|---|
| Card Security | NTAG 424 authenticity verification | Critical |
| SDM key derivation correctness | Critical | |
| Counter monotonicity enforcement | Critical | |
| Memory region access controls | High | |
| Terminal Security | Key storage protection | Critical |
| Signature generation correctness | Critical | |
| Transaction log integrity | High | |
| Smart Contracts | Reentrancy protection | Critical |
| Access control verification | Critical | |
| Slashing logic correctness | Critical |
Patent Claims Summary
The following innovations are the subject of pending patent applications. Commercial use requires licensing. Contact david@knexmail.com for licensing inquiries.
G.1 Novel Claims
- Economic Security Model for Physical Bearer Instruments: System combining merchant bonding, cryptographic commitment chains, and blockchain-based slashing to secure offline stored-value cards without expensive secure elements.
- Commitment Chain Construction: Method of linking physical card states to blockchain records via SHA-256 hash chains, enabling tamper-evident offline transactions with deterministic fraud attribution.
- SUN-Based Balance Verification: Using NTAG 424 DNA's Secure Unique NFC messaging for card authentication in stored-value payment systems.
- Tiered Settlement System: ECHELON class-based settlement frequency and bond requirements, optimizing security/capital efficiency trade-offs for different transaction value ranges.
- Offline CBDC Distribution: Method for distributing and transacting Central Bank Digital Currencies via physical NFC cards without network connectivity.
References
- NXP Semiconductors. "NTAG 424 DNA and NTAG 424 DNA TagTamper - NFC Forum Type 4 Tag IC." Product Data Sheet, Rev. 3.3, 2023.
- Buterin, V., et al. "Casper the Friendly Finality Gadget." arXiv:1710.09437, 2017.
- Stellar Development Foundation. "Soroban Smart Contracts Documentation." https://soroban.stellar.org/docs, 2024.
- Bernstein, D.J., et al. "High-speed high-security signatures." Journal of Cryptographic Engineering 2(2): 77-89, 2012. (Ed25519)
- NIST. "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication." SP 800-38B, 2005.
- World Bank. "Remittance Prices Worldwide Quarterly." Issue 52, Q4 2025.
- Bank for International Settlements. "Central bank digital currencies: foundational principles and core features." Report No. 1, 2020.
- Krawczyk, H. "Cryptographic Extraction and Key Derivation: The HKDF Scheme." CRYPTO 2010.
- ISO/IEC. "14443-3:2018 - Identification cards - Contactless integrated circuit cards - Proximity cards." International Standard, 2018.
- Oswald, E., Preneel, B. "A Survey on Passive RFID Privacy and Security Problems." Security and Privacy in Ad-hoc and Sensor Networks, 2004.