FPSF-SS-001 — Core Concepts
Layer: Core Concepts · Audience: technical evaluators, architects, developers For normative requirements, see the Formal Specification.
Why Cryptographic Payments
The dominant model of payment authorization today is delegated trust. A user instructs a financial institution, which authorizes a payment on their behalf using a credential — a card number, a PIN, a one-time code — transmitted to and verified by a chain of intermediaries. The proof of consent lives in the intermediary's records, not in the payment itself.
A cryptographically signed payment commitment is fundamentally different. It carries its own proof of authenticity. Anyone with the public key can verify that the holder of the corresponding private key produced it. The payer's intent is encoded in the data itself, bound to the specific parameters of the specific payment, and unforgeable without the payer's key.
This is not merely a technical preference. It is a meaningful shift in the locus of authority — from institution to individual, from delegated trust to verifiable proof.
System Architecture
Four principal actors drive every payment flow:
Merchant. Creates charges and receives settlement confirmation. Integrates with the Checkout Engine over mTLS. Does not interact with the blockchain.
Payer. Holds the stablecoin, signs the payment commitment, submits the payload via a compliant wallet. Never submits transactions directly to the network.
Payment Processor. Operates the off-chain infrastructure (Checkout Engine, Broadcast Layer, Relayer). Acts as the trusted intermediary between Merchants and the on-chain Settlement Contract.
Acquirer. A registered third party who distributes the payment service and earns a share of the processing fee — automatically, on-chain.
The architecture enforces clear trust boundaries. The payer's funds cannot move without their signature. The administrator of the Settlement Contract cannot move participant funds. Every operation either completes entirely or reverts entirely.
Permit-Based Payments
Normally, transferring an ERC-20 token requires the holder to send an on-chain approval transaction — which requires holding a native gas token. ERC-2612 resolves this with a permit() function: instead of an on-chain approval, the token holder signs a structured off-chain message carrying the same authorization. This signed message — the Permit — can then be submitted by any account on their behalf.
In the Stablecoin Stack, that account is the Relayer — a processor-controlled account that holds ETH and pays gas. The payer holds only the stablecoin they want to spend.
The flow is: the payer signs two off-chain messages (a Permit Signature and a Binding Signature), submits them to the Payment Processor over HTTPS, and the Relayer broadcasts a single transaction to the Settlement Contract, which verifies both signatures and executes the payment atomically.
The Dual-Signature Pattern
Every operation requires exactly two independent ECDSA signatures, serving different purposes.
The Permit Signature (permitSig) signs the ERC-2612 Permit typed-data: owner, spender, value, nonce, deadline. It is verified by the ERC-2612 token contract. It answers: "Is the token holder allowing their tokens to be moved?"
The Binding Signature (payWithPermitSig) signs the full operation parameters: token, beneficiary, orderReference, acquirerId, amount, deadline, and the permit parameters. It is verified by the Payment Processor off-chain and by the Settlement Contract on-chain. It answers: "Is the payer authorizing this specific payment with these exact parameters?"
Without the Binding Signature: the Permit Signature grants an allowance but does not determine where funds go. The processor could alter parameters without detection. Without the Permit Signature: the Binding Signature authorizes the operation but provides no gasless mechanism to pull tokens.
Together, they provide complete, binding, replay-protected payment authorization.
The Fee Model
The Stablecoin Stack defines two categories of fee, both configured and computed per token:
Operator Fee. Earned by the Payment Processor on every transfer. It has two components: a baseFeeAmount[token] (an absolute amount in token units, intended to cover at minimum the cost of on-chain execution) and an operatorFeeBps[token] (a percentage of the principal in basis points). The total Operator Fee for a transfer is baseFeeAmount[token] + floor(principal * operatorFeeBps[token] / 10000).
Acquiring Fee. Earned by a registered Acquirer when their acquirerId is included in the payment. It is floor(principal * acquiringFeeBps[acquirerWallet][token] / 10000). This is zero when the Zero-UUID is passed as acquirerId.
All fee parameters are per-token, meaning a processor can configure different economics for USDC, EURC, and any other supported token independently.
The calculateFees(token, principal, acquirerId) function returns all three outputs — operatorFee, acquiringFee, and totalWithFees — in a single call. Wallets MUST call this before constructing a permit to ensure the signed amount is correct.
The Acquiring Model
The Stablecoin Stack incorporates a first-class acquiring model that allows third parties to distribute the payment service and earn a share of the processing fee. This distribution is enforced on-chain — the processor cannot unilaterally alter an Acquirer's fee rate after registration.
Registration requires: paying a one-time acquiringPrice[token] to the Settlement Contract; selecting an acquiringFeeBps rate (subject to the per-token maxAcquiringFeeBps ceiling); and providing the wallet address to be registered.
The acquirerId is a bytes16 UUID assigned by the Settlement Contract. It is passed as a separate, explicit parameter in every payment — not embedded in another field. This means it can be independently validated, logged, and audited.
An Acquirer who wishes to be discoverable by wallet users MAY opt in to the Basic Data Service's Service Provider registry.
The Payment Flow
A payment moves through five phases. The payer's active involvement spans only phases B and the submission in C — two signature operations and one HTTPS request.
Phase A — Session Creation. The merchant creates a charge via the Checkout Engine. A 16-byte orderReference and a deadline are generated. An Ephemeral Token is issued for wallet access.
Phase B — Payload Construction. The wallet redeems the Ephemeral Token, fetches the current nonce and fee breakdown, constructs and signs PermitParams (against the token contract's domain separator) and PayWithPermitParams (against the Settlement Contract's domain separator).
Phase C — Submission. The wallet assembles and submits the TransferRequest. The processor validates it structurally, semantically, and cryptographically.
Phase D — On-Chain Settlement. The Relayer calls transferWithPermit. The Settlement Contract executes atomically. Broadcast without revert is NOT final settlement.
Phase E — Confirmation. The transfer-history service observes the PermittedTransfer event after sufficient block confirmations. The Checkout Engine reconciles the charge using orderReference. A webhook is dispatched to the merchant.
FPSF-SS-001 v1.0.0 · Draft · Fabric Payment Standards Foundation · Apache-2.0