Path 07 · Developers
Open specifications, a working reference implementation, and a test environment you can run locally in minutes. No API keys, no vendor approval, no lock-in.
What you can build
Fabric specifications define the interfaces, not the implementation. You choose what to build — a full Operator, a lightweight wallet integration, or tooling for existing systems.
CPP-001 · CashPack
Issue, renew, and redeem privacy-preserving digital bearer instruments over any settlement infrastructure — bank accounts, tokenized deposits, or public blockchains.
CPP-001 Formal Specification →SS-001 · Stablecoin Stack
Deploy the full Stablecoin Stack — Checkout Engine, Broadcast Layer, Settlement Contract — and process ERC-2612 stablecoin payments with gasless, signature-based authorisation.
SS-001 Formal Specification →MPC-001 · Disposable Keys
Run a distributed MPC node network where Ed25519 disposable keys are generated and signed without the private scalar ever existing in assembled form on any single machine.
MPC-001 Formal Specification →CPD-001 · Canonical Payment
Build any system that models, transmits, or settles payments against the canonical payment definition — the shared abstraction all other FPSF specifications build on top of.
CPD-001 Formal Specification →SS-002 · Wallet Gateway
Build a wallet client against the SS-002 interface — WebSocket transport, per-message ECDSA authentication, real-time balance subscriptions, no polling required.
SS-002 Wallet Gateway Specification →Open
Build SDKs, test harnesses, or conformance suites that help others implement and verify against FPSF specifications. Contribute them back to the ecosystem under Apache 2.0.
Open on GitHub →Specifications
All FPSF specifications are open, versioned, and published under Apache 2.0. No proprietary extensions, no closed test suites, and no tollgates on the information needed to build a conformant implementation.
The foundational abstraction — a minimal, implementation-agnostic model of what a Payment is, its lifecycle, and its interfaces. All other specs build on this.
Signed bearer instruments over any settlement infrastructure. Ed25519, RFC 8785 canonical JSON, SHA-256 chain digests. Issuance, renewal, and redemption flows fully specified.
FROST threshold signatures over Ed25519. Pedersen DKG. VRF-based group selection. Per-message authenticated REST API. Private keys that never exist in assembled form.
ERC-2612 permit-based gasless stablecoin payments. Dual-signature pattern, Settlement Contract interface, acquiring model, end-to-end flow from session creation to on-chain confirmation.
WebSocket-only transport. Per-message ECDSA authentication. Real-time balance subscriptions, transfer notifications, and asynchronous submission status lifecycle.
Reference Implementation
Every specification ships with a reference implementation that passes end-to-end tests you can run locally. Use it as a base, a conformance target, or simply to understand what the specification means in practice.
A TypeScript / Node.js implementation of a CPP-001 Operator. Express routes for
/issue, /renew, /redeem, and /status.
Ed25519 via @noble/ed25519, RFC 8785 canonical JSON, Prometheus metrics, Docker
Compose dev environment included.
Reference implementations for the SS-001 system — Settlement Contract (Solidity), Checkout Engine, Broadcast Layer, and Client Wallet. Planned as companion repositories to the specification, tracking each spec version.
Cryptographic foundations
FPSF specifications state their cryptographic requirements explicitly. No implicit trust, no proprietary signing schemes. Every primitive is referenced to a published standard and independently verifiable.
Signatures
CashPack and the MPC system use Ed25519 (RFC 8032), compatible with FROST. The Stablecoin Stack uses ECDSA over secp256k1 with EIP-712 typed data — the same scheme as native Ethereum transaction signing.
Canonicalisation
All JSON objects that are signed use RFC 8785 JSON Canonicalization Scheme before signing — deterministic, language-independent, with no ambiguity about what was signed.
Key distribution
The MPC-001 spec uses Pedersen DKG for key generation and FROST (IETF draft-irtf-cfrg-frost) for threshold signing. Output is a standard Ed25519 signature — verifiers need no FROST knowledge.
Contributing
All drafts, issues, and pull requests are public. Contributions of any size — a typo fix, a new test vector, a protocol improvement — follow the same open process.
Start with the formal specification for the component you care about. Everything normative is there — and nothing normative is anywhere else.
Found an ambiguity, a gap, or an implementation detail that doesn't match the text? File an issue on GitHub before writing code.
Fork the repo, make your change, and open a pull request with a clear description. Link to the issue. The review is public and open to anyone.
For larger protocol changes, join the relevant working group. Meetings are public and recorded. Anyone can attend; anyone can propose.
Resources
Every normative requirement, layered documentation — overview, core concepts, guides, governance, and formal spec — all in one place. All open, all Apache 2.0.
All reference implementations, test vectors, and tooling — open source under Apache 2.0. Use them, fork them, run them, extend them.
Questions about the spec, implementation details, or protocol proposals — the forum and working groups are where it happens.
The external standards FPSF specs depend on — RFC 8032, RFC 8785, EIP-712, ERC-2612, IETF FROST, and more. Every dependency is stated explicitly.
The specs are there, the reference implementation runs, and the community is open. Nothing to sign up for.