Skip to main content

FPSF-CPP-002 — CashPack Offline Device Extension

Extension Layer — NORMATIVE This document extends FPSF-CPP-001 (CashPack Protocol, CPP-1.0). It does not redefine or override any CPP-1.0 data structure, obligation, or Operator interface except where explicitly stated. Where this document is silent, CPP-1.0 governs.

Document Metadata​

FieldValue
Document IDFPSF-CPP-002
TitleCashPack Offline Device Extension
Version0.1.0
StatusDraft
Date2026-08-13
Author(s)Adalton Reis — [email protected]
Reviewers—
OrganizationFabric Payment Standards Foundation
Specification FamilyCashPack Protocol (CPP)
Conforms ToFPSF-CPP-001 v1.0.0, FPSF-CPD-001
Canonical URLhttps://fabricpaymentstandards.org/specs/cashpack/cpp-002
Contact[email protected]
LicenceApache License 2.0

1. Scope​

CPP-1.0 assumes every renewal and redemption is countersigned by the Operator in real time. This assumption fails when neither bearer has network access — a common condition for a purpose-built payment wearable or card-form device operating in areas of poor connectivity, or simply while a phone is in airplane mode.

This document specifies CPP-002, a hardware and protocol extension that allows a Cash-Pack instrument to be renewed one or more times without contacting the Operator, by transferring custody directly between two Certified Devices over a local, non-networked transport. It defines:

  • The hardware trust requirements a device MUST satisfy to participate ("Certified Device").
  • The device certification and attestation chain rooted in the Foundation.
  • The offline transfer protocol and the data structures it produces.
  • The hardware- and software-enforced mechanism that prevents double-spending an instrument in the absence of an Operator.
  • The mandatory reconciliation procedure by which offline transfers are surfaced to, and validated by, the Operator once connectivity is restored.

Out of scope: industrial design, specific form factor, battery/power management, the companion application's user interface, and any payment rail other than CPP-1.0 Cash-Pack instruments. This document does not define a new settlement model, a new instrument type, or any consensus mechanism between devices.

2. Relationship to CPP-1.0 and CPD-001​

CPP-002 is additive. A Cash-Pack instrument transferred exclusively through Certified Devices, or through a mixture of online and offline hops, remains a single CPP-1.0 instrument with a single pack_id, a single Operator, and a single renewal_chain. Offline hops are appended to that same chain as a distinct entry type (Section 6) once reconciled.

CPP-002 introduces no new concept of Payment or Value beyond what FPSF-CPD-001 already defines. A device custody transfer is a Renewal in the CPD-001 sense: it changes current_bearer_pk without changing value, amount, or currency.

CPP-002 does not introduce a device-to-device consensus mechanism, a distributed ledger among devices, or any settlement authority independent of the Operator. The Operator remains the sole source of truth. Certified Devices are a hardware-enforced custody control, not a second trust root.

3. Terminology​

TermDefinition
Certified DeviceA physical device that has passed the Foundation's Device Certification Program (Section 9) and holds a valid, unrevoked Device Certificate.
Secure Element (SE)A tamper-resistant hardware component within a Certified Device responsible for key generation, key storage, signing, and enforcement of the Possession Invariant (Section 7.1). Private key material MUST NOT leave the SE in any form.
Device Root KeyAn asymmetric key pair generated inside the SE at first boot (or at manufacture, under Foundation-audited conditions) and never exported. Its public key, once certified, is the device's permanent identity.
Device CertificateAn X.509-style certificate binding a Device Root Key's public key to a device identity, issued by an accredited Device Vendor CA, itself certified by the Foundation Device Root CA.
Companion ApplicationA smartphone or desktop application that renders UI, relays Bluetooth packets, and displays instrument state. It holds no signing authority and cannot construct or alter offline transfer data. Analogous to the CPP-1.0 wallet/frontend — never referred to as a "wallet" in Foundation materials.
Verified Boot ChainThe sequence of cryptographic checks (ROM → bootloader → OS → application) that MUST succeed before the SE unseals any key material.
Offline Transfer Entry (OTE)The offline analogue of a CPP-1.0 Renewal Entry: a signed record of a custody change produced by two Certified Devices without Operator countersignature, pending reconciliation.
Custody ChainThe ordered sequence of Offline Transfer Entries produced since the instrument last had an Operator-countersigned state.
ReconciliationThe mandatory process, performed when a device regains network access, by which a Custody Chain is submitted to the Operator for validation and folded into the instrument's authoritative renewal_chain.
Possession InvariantThe hardware-enforced guarantee that at any instant, at most one Certified Device holds a live, spendable copy of a given instrument's custody state.
Quarantine StateA state assigned by the Operator to an instrument whose Custody Chain cannot be fully validated (e.g. it touched a revoked device), pending manual or policy-driven resolution.
Device Revocation List (DRL)A Foundation- and Vendor-signed list of Device Certificates that MUST no longer be trusted as counterparties or reconciliation submitters.

4. Trust Model​

CPP-002 extends, and does not weaken, the CPP-1.0 trust model described in CPP-1.0 Core Concepts §2.

  • The Operator remains the single source of truth. An offline hop is provisional until reconciled; it confers no finality on its own.
  • The Certified Device is a hardware-enforced custody control, trusted only to the extent that its attestation chain is valid and unrevoked. A device is not a settlement authority and cannot itself mark an instrument redeemed, cancelled, or expired.
  • There is no device-to-device consensus. Two devices exchanging an instrument do not vote, do not require a quorum, and do not reference any ledger other than the instrument itself and their own local attested state.
  • Bearer privacy is preserved for offline hops in the same manner as CPP-1.0: intermediate device identities are not disclosed to the Operator beyond what is structurally necessary to validate the Custody Chain at reconciliation (Section 8).
  • Manufacturer trust is delegated, not absolute. A Device Vendor's ability to issue Device Certificates is itself certified, audited, and revocable by the Foundation (Section 9). A Vendor compromise degrades to a DRL event, not a protocol failure.

5. Hardware Requirements​

A device MUST satisfy all of the following to be eligible for certification.

5.1 Secure Boot​

  • The device MUST implement a Verified Boot Chain rooted in an immutable, factory-programmed public key (or key hash).
  • Every stage of the boot chain MUST cryptographically verify the next stage before executing it.
  • On verification failure at any stage, the device MUST halt or enter a non-functional recovery mode. It MUST NOT unseal SE key material.
  • Boot chain measurements MUST be available to remote attestation (Section 5.4).

5.2 Secure Element and Key Generation​

  • The device MUST contain a Secure Element (discrete chip, or an equivalently certified isolated execution environment) meeting a Foundation-recognised hardware security standard (e.g. Common Criteria EAL5+ or equivalent; the Foundation publishes an accepted-standards list separately from this document).
  • The Device Root Key MUST be generated on-device, inside the SE. It MUST NOT be generated off-device and injected, except under the audited manufacture-time provisioning procedure defined by the Device Certification Program, which MUST itself use an on-die TRNG and MUST NOT retain the private key outside the SE after provisioning.
  • All instrument bearer keys used for offline custody (Section 6.1) MUST likewise be generated inside the SE, one per instrument or per session as the implementation elects, and MUST NOT be exportable in cleartext under any API, debug interface, or manufacturer backdoor.
  • The SE MUST enforce that only Verified Boot–attested application software can request signing operations.

5.3 Tamper Resistance​

  • The SE MUST implement physical tamper detection (e.g. voltage/clock glitch detection, die shield) and MUST zeroise key material on detected tamper events.
  • The device MUST NOT expose a debug or JTAG interface capable of reading SE memory in production units. Any such interface MUST be permanently fused off before the device leaves manufacture-time provisioning.

5.4 Remote Attestation​

  • The device MUST be able to produce a signed attestation statement, using a manufacture-time Attestation Key distinct from the Device Root Key, covering: boot chain measurements, application software hash, and current Device Certificate.
  • Attestation statements are exchanged during device pairing (Section 6.2) and during reconciliation (Section 8).

5.5 Connectivity and UI​

  • The device MUST support at minimum Bluetooth Low Energy (BLE) as the local offline transport. Additional local transports (NFC, ultra-wideband) MAY be supported under the same protocol obligations.
  • The device MAY have no display or input surface of its own. Where it has none, all human-readable presentation of instrument state, amounts, and confirmation prompts MUST be delegated to the Companion Application, subject to Section 10.
  • The device MUST NOT require a persistent network connection to perform an offline transfer. It MUST require one to complete Reconciliation (Section 8).

6. Data Structures​

6.1 Device Bearer Key​

Each Certified Device holds, per instrument in its custody, a bearer key pair generated per Section 5.2. Its public key is used exactly as current_bearer_pk / incoming_bearer_pk / outgoing_bearer_pk are used in CPP-1.0 — CPP-002 introduces no new key type at the protocol level, only a hardware-enforced generation and storage requirement for it.

6.2 Device Attestation Certificate​

DeviceAttestation {
    version: "CPP-2.0"
    device_id: UUIDv4                     // assigned at certification
    device_pubkey: Base64url               // Device Root Key public key
    vendor_id: string
    boot_measurements: Base64url           // hash chain of verified boot stages
    app_software_hash: hex
    issued_at: RFC3339
    vendor_signature: Base64url            // Device Vendor CA signature
}

6.3 Offline Transfer Entry (OTE)​

Structurally parallel to the CPP-1.0 Renewal Entry, with attestation in place of Operator countersignature and a monotonic anti-replay counter in place of Operator-assigned ordering.

OfflineTransferEntry {
    ote_id: UUIDv4
    timestamp: RFC3339                        // device local clock, best-effort
    outgoing_device_id: UUIDv4
    incoming_device_id: UUIDv4
    outgoing_bearer_pk: Base64url              // MUST match instrument's current_bearer_pk
    incoming_bearer_pk: Base64url
    prev_chain_digest: hex                     // as in CPP-1.0 chain_digest
    outgoing_seq: integer                      // monotonic counter, this device, this instrument
    outgoing_bearer_signature: Base64url        // signs all fields above
    outgoing_attestation: DeviceAttestation
    incoming_attestation: DeviceAttestation
    handoff_commit_proof: Base64url             // see Section 7.2
}

handoff_commit_proof is the artefact produced by the atomic handoff protocol (Section 7.2) and is the object the Operator inspects most closely at reconciliation, since it is the evidence that the Possession Invariant was honoured.

6.4 Custody Chain​

An ordered array of OfflineTransferEntry objects, carried by the instrument alongside its CPP-1.0 fields for the duration of its offline life, and cleared upon successful Reconciliation (at which point its entries are translated into standard RenewalEntry objects per Section 8.3).

7. Offline Transfer Protocol​

7.1 The Possession Invariant​

The central guarantee CPP-002 must provide, in the absence of an Operator, is:

At any instant, at most one Certified Device holds a usable custody state (bearer private key + associated signing authority) for a given instrument.

This is enforced entirely inside the SE and Verified Boot application software, not by any external agreement between devices, and not by any distributed ledger. It follows from three properties, each individually enforced:

  1. Non-exportability. A bearer private key generated per Section 5.2 cannot leave the SE in usable form under any circumstance, including device compromise short of physical extraction defeating Section 5.3 tamper protections.
  2. Atomic, destructive handoff. The outgoing device's SE deletes (zeroises) its local signing capability for the instrument as an uninterruptible step of the same transaction that produces the outgoing signature over the OfflineTransferEntry, per the commit protocol in Section 7.2. There is no state in which the outgoing device retains signing capability after producing a valid outgoing_bearer_signature.
  3. Refusal of concurrent sessions. A device's application software, itself Verified-Boot-attested, MUST reject any request to open a second concurrent offline-transfer session for the same instrument while one is in progress.

Properties 1–3 together mean that forging a double-spend offline requires defeating the Secure Element's physical tamper protections on a specific, previously-legitimately-held device — not merely compromising software, replaying network traffic, or colluding with another party. This is why Section 5's hardware bar is high and non-negotiable: CPP-002's entire double-spend defence rests on the SE, not on the protocol messages.

7.2 Handoff Commit Protocol​

The BLE exchange between an outgoing device (A, current bearer) and an incoming device (B, next bearer) proceeds as a three-phase commit designed so that an interruption at any point leaves the instrument fully spendable by exactly one device — never zero, and never two.

  1. Attestation Exchange. A and B exchange DeviceAttestation objects and verify each other's Device Certificate against a locally cached DRL snapshot (Section 8.4). Either device MAY abort here with no state change on either side.
  2. Proposal. B generates a fresh bearer key pair for the instrument (Section 6.1) and sends its public key to A along with a session nonce. A constructs the OfflineTransferEntry (minus handoff_commit_proof) and computes outgoing_bearer_signature.
  3. Commit. A's SE performs, as a single atomic operation with no externally observable intermediate state: a. Persist the signed OfflineTransferEntry to A's local Custody Chain log. b. Zeroise A's local bearer signing capability for this instrument. c. Emit handoff_commit_proof — an SE-signed statement of (a) and (b) having completed, bound to the session nonce. A transmits the completed OfflineTransferEntry (including handoff_commit_proof) to B.
  4. Acknowledgement. B verifies the entry, verifies handoff_commit_proof against A's attestation key, and — only after successful verification — activates its own local signing capability for the instrument and appends the entry to its Custody Chain. B sends a signed acknowledgement to A.

If step 3 completes on A's side but the transmission to B in step 3 or B's activation in step 4 never completes (e.g. BLE link drop, device powered off), the instrument is temporarily unspendable by any device until B successfully replays the already-committed OfflineTransferEntry from A's retained log (A retains the entry and proof for retransmission even after zeroising its own signing capability — retaining the record is not the same as retaining signing capability). This is a deliberate design choice: an interrupted handoff MUST fail closed (instrument temporarily frozen) rather than fail open (instrument spendable twice).

7.3 Chain Depth and Expiry Under Offline Operation​

  • An instrument's Custody Chain (offline-only segment) MUST NOT exceed a Foundation-recommended maximum depth of 5 consecutive offline hops before Reconciliation becomes mandatory before any further transfer, online or offline. Operators MAY set a stricter limit in their Policy Document (CPP-1.0 §4.4 as extended by Section 11).
  • An instrument accumulating any offline hops MUST carry an effective expiry no later than the lesser of its original CPP-1.0 expiry and a Foundation-recommended 72-hour offline ceiling from the first unreconciled OfflineTransferEntry, to bound the Operator's exposure to a chain it has not yet seen.

8. Reconciliation​

8.1 Trigger​

A device MUST initiate Reconciliation for any instrument carrying a non-empty Custody Chain as soon as it (or, for the current bearer specifically, its Companion Application) regains network access. A device MUST NOT permit that instrument to be used in a further online renewal or a redemption request before Reconciliation succeeds.

8.2 Submission​

The current bearer's Companion Application submits, to the Operator's /v1/cashpack/renew endpoint (CPP-1.0 §4.2, invoked once per Custody Chain entry) or a dedicated /v1/cashpack/reconcile endpoint (RECOMMENDED, to allow atomic multi-entry submission), the full ordered Custody Chain alongside the last Operator-countersigned instrument state.

8.3 Operator Validation​

For each OfflineTransferEntry in order, the Operator MUST:

  1. Verify outgoing_bearer_signature against outgoing_bearer_pk, and verify outgoing_bearer_pk matches the instrument's current_bearer_pk (or the incoming_bearer_pk of the immediately preceding entry).
  2. Verify prev_chain_digest continuity, exactly as CPP-1.0 §4.2 obligation 5.
  3. Verify both outgoing_attestation and incoming_attestation chain to a valid Foundation Device Root CA via their Device Vendor CA, and that neither device appears in the Device Revocation List as of the entry's timestamp.
  4. Verify handoff_commit_proof against the outgoing device's attestation key.
  5. Verify the offline chain depth and elapsed time do not exceed the limits in Section 7.3.

On success for the full chain, the Operator MUST translate each OfflineTransferEntry into a standard CPP-1.0 RenewalEntry (mapping outgoing_bearer_signature → outgoing_bearer_signature, and adding its own operator_renewal_signature per entry, per CPP-1.0 §3.3), append them to renewal_chain in order, and recompute chain_digest accordingly. The instrument's Custody Chain is then cleared.

On failure of any single entry, the Operator MUST NOT reconcile the entries after the point of failure and MUST set the instrument to Quarantine State (Section 8.5) rather than silently dropping the offline hops.

8.4 Device Revocation List Distribution​

  • The Foundation publishes the canonical DRL at a well-known URL (/.well-known/cashpack-device-revocations.json), Foundation-signed, updated on a published cadence.
  • Operators MUST fetch and honour the current DRL at Reconciliation time (Section 8.3, step 3).
  • Certified Devices SHOULD cache the DRL locally and refresh it opportunistically whenever network access is available, so that Attestation Exchange (Section 7.2, step 1) can reject a known-revoked counterparty even while fully offline, using the most recent cached snapshot. A stale local DRL is a known and accepted limitation of offline operation; it is why the Operator's authoritative DRL check at Reconciliation is mandatory regardless of what the devices believed at handoff time.

8.5 Quarantine State​

An instrument in Quarantine State MUST NOT be redeemed or further renewed until resolved. Resolution is an Operator policy matter (manual review, automatic return-to-principal, or partial acceptance up to the last valid entry) and is out of scope for this document beyond requiring that Operators publish their Quarantine resolution policy in their Policy Document (Section 11).

9. Device Certification Program​

  • The Foundation operates a Device Certification Program, accrediting Device Vendors who may issue Device Certificates under a Foundation-issued Vendor CA certificate.
  • Certification requires an independent audit against Section 5's hardware requirements, performed by a Foundation-recognised laboratory. The Foundation publishes the accepted-standards and accepted-laboratories lists separately from this document.
  • The Foundation MAY revoke a Vendor's CA certification for cause (systemic hardware failure, key compromise, non-cooperation with audit), which propagates as bulk entries on the DRL for that vendor's device population, subject to a published transition period to protect bearers holding legitimately-obtained devices.
  • Certification is a hardware and software supply-chain control, not a governance seat. Vendor accreditation confers no voting rights, board seats, or influence over Foundation governance; those are granted solely according to the Foundation's charter and by-laws, on equal terms to institutions of any size (see FPSF Governance Framework).
  • The Companion Application MUST clearly present, before the device commits to Step 7.2 Proposal, the instrument amount, currency, and counterparty device identifier (or a human-friendly label bound to it) to the bearer, and MUST require explicit confirmation.
  • The Companion Application holds no signing authority and cannot itself produce, alter, or replay an OfflineTransferEntry; it is a display and relay surface only, structurally analogous to a wallet frontend in CPP-1.0 and never itself termed a "wallet" in Foundation materials.
  • Devices without a display MUST refuse to complete Step 7.2 Proposal in the absence of a connected, unlocked Companion Application able to render the confirmation prompt, except where the bearer has explicitly configured a bounded auto-accept policy (e.g. amount ceiling) on a prior online session — such a policy MUST itself be countersigned by the bearer's device key and MUST be revocable at any time the Companion Application is reachable.

11. Operator Obligations​

An Operator supporting CPP-002 MUST extend its Policy Document (CPP-1.0 §4.4) with:

  • Whether offline (Certified Device) transfers are accepted at all.
  • Maximum offline chain depth and maximum offline duration, at or below the Section 7.3 ceilings.
  • Its Quarantine resolution policy (Section 8.5).
  • The DRL source(s) it honours, if supplementary to the Foundation canonical DRL.

An Operator MUST NOT treat an offline hop as final, and MUST NOT release funds or otherwise recognise a redemption based on an unreconciled Custody Chain.

12. Security Considerations​

ThreatMitigation
Double-spend via retained key after handoffPossession Invariant (§7.1), atomic zeroise-on-commit (§7.2)
Handoff interrupted mid-transferFail-closed design: instrument temporarily frozen, not duplicated (§7.2)
Physical extraction of SE key materialTamper-resistant SE required by certification (§5.3)
Cloned or counterfeit deviceDevice Certificate chain verification at Attestation Exchange and at Reconciliation (§7.2, §8.3)
Compromised device continuing to transact after detectionDevice Revocation List, checked authoritatively at Reconciliation regardless of local cache staleness (§8.4)
Vendor-level compromiseVendor CA revocation, bulk DRL propagation, published transition period (§9)
Companion Application forging a transferApplication holds no signing authority; all signatures originate in the SE (§10)
Unbounded offline exposure to the OperatorMandatory chain-depth and duration ceilings (§7.3)
Instrument stranded after QuarantineOperator-published Quarantine resolution policy (§8.5, §11)

13. Non-Goals​

This specification intentionally avoids:

  • Defining a specific device form factor (wearable, card, fob, or otherwise) — any form factor meeting Section 5 qualifies.
  • Introducing consensus, voting, or a distributed ledger among devices.
  • Granting devices or vendors any settlement authority independent of the Operator.
  • Defining battery, power, or industrial design requirements.
  • Defining the Companion Application's UI beyond the consent obligations in Section 10.

14. Open Questions and Future Work​

  1. Multi-hop offline mesh routing. This version assumes direct device-to-device BLE pairing per hop. Store-and-forward relay through intermediate Certified Devices that are not themselves bearers is not yet specified.
  2. Cross-Operator offline transfer. As with CPP-1.0 Phase 2 inter-Operator settlement, an instrument changing Operators mid-offline-chain is out of scope for v0.1.0.
  3. Bounded auto-accept policy format. Section 10's auto-accept mechanism needs a normative data structure; deferred to a subsequent revision.
  4. Accepted hardware security standards list and accepted laboratories list. To be published and maintained as a living Foundation reference document, not embedded in this specification.

CashPack Offline Device Extension CPP-002 · DRAFT · Extends CPP-1.0 · For Discussion and Adoption © 2026 Fabric Payment Standards Foundation — Licensed under Apache License 2.0