Canonical Architecture

An open, layered payment architecture that standardizes payment intent, signing, and settlement across stablecoins and banking systems.

The Architecture

Four layers of open, interoperable payment infrastructure

Layer 1: Applications
Wallets · Merchants · Banks · Payment Service Providers

What this layer is: Consumer and business-facing applications that create and consume payment intents.

What ZFF does NOT do: We do not build consumer apps or compete with existing applications.

Key principle: Any application can generate or consume a standard payment intent.

Layer 2: Payment Intent & Signing
Standard payloads · Cryptographic signatures · Offline instruments

This is the heart of the foundation: Defines canonical payment intent format and signing rules.

What a payment intent is: A signed, portable description of who pays whom, how much, under what conditions.

Properties: Rail-agnostic, cryptographically verifiable, serializable, can exist before settlement.

Layer 3: Settlement & Rail Adapters
Stablecoins · Bank transfers · Card systems

Purpose: Translate signed payment intents into actual settlement on specific rails.

Examples: Stablecoin adapter (USDC, EURC), Bank transfer adapter (SEPA, ACH), Card adapter.

Key principle: Settlement is an implementation detail — intent is universal.

Layer 4: Existing Infrastructure
Blockchains · Banks · Card Networks

What this layer is: The existing financial infrastructure that we compose with, not replace.

You do not replace: Banks, Blockchains, Card networks.

This is why: Regulators and institutions can engage without existential fear.

What This Architecture Enables

Real-world benefits of open payment infrastructure

Stablecoins as Everyday Payments

Enable stablecoins to be used seamlessly for daily transactions without proprietary gateways or complex integrations.

Bank-Compatible Digital Payments

Bridge the gap between traditional banking systems and digital payment methods through standardized interfaces.

Offline-Capable Electronic Cheques

Create payment instruments that work with limited connectivity, expanding financial inclusion globally.

Interoperable Wallets and Merchants

Enable seamless transactions between different wallet providers and merchant systems without custom integrations.

Neutral, Open Governance

Establish governance structures that serve all participants equally, preventing vendor lock-in.

Regulatory Compatibility

Maintain all regulatory enforcement at the settlement layer while improving auditability and transparency.

What This Architecture Is NOT

Clarifying misconceptions about our approach

Common Misconceptions

  • A payment processor: We define standards, not processing services
  • A wallet: We enable wallet interoperability, don't compete with wallets
  • A bank: We work with banks, don't replace them
  • A token or asset: We standardize how payments work, not what they are
  • A shortcut around regulation: We enhance compliance, don't bypass it

What We Actually Do

  • Infrastructure: Define technical standards and protocols
  • Coordination: Facilitate collaboration between stakeholders
  • Reference implementations: Provide examples and tools
  • Documentation: Maintain clear specifications and guides
  • Governance: Establish neutral decision-making processes

End-to-End Flow

How payment intents move through the architecture

1. Intent Creation

Application creates a payment intent with all necessary details and conditions.

2. Cryptographic Signing

Intent is signed by the payer using standardized cryptographic methods.

3. Transmission

Intent is transmitted via online or offline methods (QR, NFC, API, etc.).

4. Verification

Receiver verifies the signature and validates the intent without external calls.

5. Settlement Execution

A settlement adapter executes the transfer on the chosen payment rail.

6. Proof Attachment

Settlement proof is attached back to the intent for complete audit trail.

Use Cases

Real-world scenarios enabled by this architecture

Crypto to Crypto

Seamless transfers between different stablecoins and cryptocurrencies using standardized payment intents.

Bank to Bank

Modernized bank transfers with improved transparency and reduced integration complexity.

Crypto to Bank

Bridge between digital assets and traditional banking systems without proprietary gateways.

Offline to Online

Payment instruments that work in areas with limited connectivity and settle when connectivity is restored.

How Projects Map to Architecture

Foundation projects organized by architectural layer

Layer 1: Applications

Project Types: Reference apps, demos, SDKs for application developers

Goal: Demonstrate how to create and consume payment intents

Layer 2: Intent & Signing

Project Types: Core protocols, standards, cryptographic libraries

Goal: Define and maintain the canonical payment intent specification

Layer 3: Settlement Adapters

Project Types: Stablecoin adapters, bank transfer adapters, card adapters

Goal: Enable payment intents to settle on various financial rails

Layer 4: Tooling

Project Types: SDKs, test suites, validators, developer tools

Goal: Support development and testing of payment infrastructure