Skip to main content

FPSF-CPP-001 — Guides

Layer: Guides · Audience: developers, integration teams, product implementors For normative requirements, see the Formal Specification.

Guide 1: The Issuance Flow (Bob issues to Alice)​

Bob is the Principal. Alice is the intended first bearer.

Prerequisites​

  • Bob is a KYC-verified account holder with the Operator.
  • Bob has a key pair (generated by the Operator's app or a compatible tool).
  • Alice has provided Bob with her public key through any out-of-band channel.

Steps​

  1. Bob constructs a Lock Request containing: his public key, Alice's public key, the amount, the currency, the Operator identifier, a unique request ID, and a timestamp.
  2. Bob signs the Lock Request with his private key.
  3. Bob submits the signed Lock Request to POST /v1/cashpack/issue.
  4. The Operator authenticates Bob, verifies his signature, checks his available balance, and confirms the amount does not exceed the configured maximum.
  5. The Operator locks the amount, constructs the cash-pack instrument, and signs it.
  6. The Operator returns the signed cash-pack to Bob.
  7. Bob delivers the cash-pack to Alice through any channel.

The cash-pack is a JSON document. Bob can send it as a file, a QR code, over an encrypted message, or in any other way. The Operator is not involved in delivery — only in issuance, renewal, and redemption.

Guide 2: The Renewal Flow (Alice transfers to John)​

Alice holds a cash-pack and wants to pass it to John.

Prerequisites​

  • Alice holds a cash-pack where current_bearer_pk matches her public key.
  • John has provided Alice with his public key.
  • Alice has network access to the Operator's renewal endpoint.

Steps​

  1. Alice constructs a Renewal Entry: her public key as outgoing bearer, John's public key as incoming bearer, the current chain digest, and a timestamp.
  2. Alice signs the Renewal Entry with her private key.
  3. Alice submits the current cash-pack plus the Renewal Entry to POST /v1/cashpack/renew.
  4. The Operator verifies: its own prior signature on the instrument, Alice's signature on the entry, that Alice's key matches current_bearer_pk, and that the chain digest is consistent.
  5. The Operator updates current_bearer_pk to John's public key, appends the Renewal Entry, recomputes the chain digest, re-signs the instrument, and returns it to Alice.
  6. Alice delivers the updated cash-pack to John.

The Operator processes Alice's renewal but does not know who Alice is — only her public key. If Alice used a disposable key pair, that key has never appeared in any prior transaction and will never appear again.

Chaining Renewals​

John can repeat this exact process for any subsequent bearer. The renewal_chain in the instrument grows by one entry per hop. Operators impose a maximum chain depth; the recommended minimum is 20 hops.

Guide 3: The Redemption Flow (Final bearer redeems for funds)​

Prerequisites​

  • The bearer holds a cash-pack where current_bearer_pk matches their public key.
  • The instrument is ACTIVE and has not expired.
  • The bearer is identifiable to the Operator.

Steps​

  1. The bearer constructs a Redemption Request: pack_id, their public key, a payout destination, and a timestamp.
  2. The bearer signs the Redemption Request with their private key.
  3. The bearer submits the Redemption Request plus the full cash-pack to POST /v1/cashpack/redeem.
  4. The Operator verifies all signatures in the chain and confirms the bearer's identity.
  5. The Operator marks the instrument REDEEMED, releases funds to the payout destination, and returns a signed Redemption Confirmation.

The redeemer's identity is necessarily disclosed to the Operator at redemption. This is by design and is a regulatory requirement. The protocol does not attempt to conceal the redemption edge.

Guide 4: Using Disposable Keys​

For maximum privacy, every participant other than the original Principal should generate a fresh key pair specifically for each instrument they receive.

Generating a disposable key pair​

# Using OpenSSL
openssl genpkey -algorithm ed25519 -out disposable_sk.pem
openssl pkey -in disposable_sk.pem -pubout -out disposable_pk.pem

The public key (base64url encoded) is what you share with the sender. The private key signs your Renewal or Redemption request. Discard both after the instrument is renewed or redeemed.

For higher-assurance deployments — particularly where keys must be generated without any single party holding the private key — use FPSF-MPC-001 to generate disposable keys via multi-party computation.

Guide 5: Extended Use Cases​

Tokenized Deposits​

An Operator running a tokenized deposit system can issue cash-packs whose locked value corresponds to a tokenized deposit held in escrow. The token is locked at issuance and transferred (or burned and reissued) at redemption. The cash-pack provides the privacy-preserving bearer layer above the token's settlement infrastructure.

Digital Securities and Bearer Bonds​

A bond issuer acting as Operator can issue cash-packs representing bearer bond entitlements. The instrument passes among investors without on-chain transfers at each step. Only the final holder's identity is disclosed at settlement. The renewal chain provides a complete provenance record for regulatory purposes.

Merchant Vouchers and Gift Instruments​

A retailer or platform acting as Operator can issue cash-packs as vouchers or gift instruments. Recipients can pass them freely. Redemption is at point of sale or service.

Cross-Border Payments (Phase 2)​

Two Operators in different jurisdictions may establish a bilateral settlement agreement allowing one Operator's cash-packs to be redeemed by the other. This phase requires inter-Operator protocol extensions not defined in CPP-1.0.

FPSF-CPP-001 v1.0.0 · Draft · Fabric Payment Standards Foundation · Apache-2.0