Path 06 · Researchers & Academics
Every FPSF specification is published with full formal definitions, normative references, and explicit design rationale. The work is open — not just in licence but in process. Researchers are among the most valuable contributors we have.
Specification index
Each specification defines its scope, normative references, cryptographic requirements, data structures, and protocol obligations explicitly. Click any row for a research-oriented summary.
Minimal, implementation-agnostic model of a Payment and Digital Payment
Defines the canonical model of a Payment independent of medium, infrastructure, or jurisdiction. Establishes entities (Participant, Value, Payment Object, Intent Descriptor, Authorization Proof, Execution Context), lifecycle states (CREATED → AUTHORIZED → IN_FLIGHT → SETTLED/FAILED/CANCELLED), and conceptual interfaces.
None mandated at the base layer. AuthorizationProof is defined as opaque with examples including cryptographic signature and multi-party approval. Specific cryptographic bindings are left to extending specifications.
Uniqueness, integrity (data immutable post-authorization), authorization binding (proof bound to payer + value + payee), deterministic state (exactly one state at any moment), finality (SETTLED/FAILED/CANCELLED are terminal).
Signed bearer instruments — issuance, renewal chain, and redemption
Defines data structures for Lock Request, Cash-Pack Instrument, Renewal Entry, and Redemption Request. Specifies Operator protocol obligations at issuance, renewal, and redemption. Defines versioning, extension rules, and conformance.
Ed25519 (RFC 8032) required. ECDSA P-256
optional for HSM-constrained deployments. SHA-256 for chain digest computation:
chain_digest[n] = SHA256(chain_digest[n-1] || canonical_json(entry[n])).
All JSON signed via RFC 8785 (JCS).
Edge-KYC: Principal and redeemer are identified. Intermediate bearers are not identified to the Operator. Full renewal chain (all public keys + timestamps) is retained by the Operator and available under legal process.
Distributed threshold signature system — FROST, Pedersen DKG, VRF group selection
Specifies a multi-party computation threshold signature system for generating and operating disposable Ed25519 keys. Covers node lifecycle, group formation, DKG protocol, signing protocol, share storage, anti-collusion mechanisms, fault tolerance, and public REST API.
Ed25519 throughout. Pedersen DKG for key generation. FROST (IETF draft-irtf-cfrg-frost) for threshold signing — output is standard Ed25519. VRF for anti-collusion group selection. mTLS with X.509 for node identity. AES-256-GCM for share storage; storage key derived via HKDF-SHA-256.
Up to t−1 nodes may be compromised without affecting security. Coordinator is trusted for availability but cannot obtain key material. VRF group selection with published proof prevents biased selection. Opaque session-scoped node handles prevent cross-session correlation.
ERC-2612 gasless stablecoin payments — dual-signature, Settlement Contract, acquiring model
Full architecture spec: system components, trust boundaries, cryptographic conventions, data structures (ERC20RelayerSig, PermitParams, PayWithPermitParams, BuyAcquiringPackPermitParams), Settlement Contract interface, validation rules, end-to-end flow, security model, and conformance requirements.
Dual-signature: Permit Signature (ERC-2612,
validated by token contract) + Binding Signature (EIP-712 over full operation
params, validated by Settlement Contract). Replay protection: ERC-2612 nonce +
usedHashes registry. Payer-agnostic execution — msg.sender
is irrelevant to validity.
Gas abstraction baseline — payer needs only the stablecoin. On-chain acquiring model with immutable fee percentages. Non-custodial administration — Administrator cannot move participant funds. Atomic settlement or full revert — no partial execution.
WebSocket-only transport — per-message ECDSA auth, subscription model, async status lifecycle
Transport model, connection management (single-connection-per-wallet constraint, idle timeout), per-message ECDSA authentication, wallet initialisation, request-response operations, subscription model, asynchronous submission status lifecycle, error handling, and conformance requirements.
Stateless — every message individually signed. No
sessions, cookies, or API keys. Message envelope:
type + callerAddress + deadline + payloadHash, signed via EIP-712.
Gateway independently recomputes digest and verifies recovered address equals
callerAddress.
WebSocket-only because on-chain confirmation is inherently asynchronous — latency spans multiple block intervals. Single-connection-per-wallet prevents stale sessions receiving notifications after supersession. Subscription state is connection-scoped and not persisted.
Open questions
Each specification closes with a list of open questions and future work items. These are genuine research problems — not placeholders. Contributions that address them are among the most valuable the Foundation can receive.
MPC-001
Periodically re-randomising shares without changing the public key would mitigate long-term share exposure. This requires a re-sharing protocol that maintains security during the refresh. Not in scope for v1 — the right approach is an open question.
MPC-001
Changing (t, n) for an existing key after creation without changing the public key requires a full re-sharing protocol. The security model for this — particularly during the transition window — is not yet specified.
CPP-001
In the MPC-001 authentication model, a mechanism for revoking
specific sub-keys without using the root key is not yet defined. The optional
expires_at field provides partial mitigation but not active revocation.
SS-001
The current Settlement Contract applies a uniform
baseFeeAmount across all tokens. A forthcoming revision will introduce per-token
fee configuration — the specification acknowledges this gap and reserves the
domainSeparator parameter in GET_FEES for this purpose.
Planned
A regulated, centralised equivalent of DID — a global identifier for a payment participant that works across jurisdictions without coupling all layers together. Similar to TCP/IP for addresses. IBANs are the closest existing thing but couple all layers. A new specification is planned.
Planned
Constructing and authenticating a payment commitment without a live network connection — particularly relevant for populations with intermittent connectivity. Identified as a priority across multiple specifications. No solution is currently specified.
Contributing
The Foundation builds, tests, and then specifies — not the other way around. Researchers who engage critically with the specifications, identify gaps, or contribute formal analysis are making the work better in the most direct way possible.
All specifications are versioned, dated, and permanently archived. You can cite any version by its Document ID and version number. The canonical URL is stable. Apache 2.0 permits reproduction with attribution.
If you find an ambiguity, a gap in the security model, or a property the specification claims that doesn't hold — file a GitHub issue with a precise description. These are taken seriously and tracked in the working group process.
Working group meetings are public and open to observers. For open questions — especially those involving cryptographic protocol design — academic input is among the most valuable the Foundation receives. No affiliation required.
Resources
All formal specifications and their normative external references — RFC 8032, RFC 8785, EIP-712, ERC-2612, IETF FROST, FIPS 186-4, and others — fully listed per specification.
Working reference implementations that pass end-to-end lifecycle tests. Useful for verifying your understanding of the specification against executable behaviour.
Working group observer status, formal reviews, and co-authorship on future specifications are all open. Reach out.