This section explains the architectural principles and intellectual property that enable Crunchfish’s offline payment capability to scale safely within and across payment ecosystems, without compromising governance, settlement discipline, or regulatory control.
Crunchfish enables offline payments through a Layer-2 solution that operates above existing payment systems. Payments are executed offline under strict local controls, while funds, reservations, ledger authority, and final settlement always remain native to the underlying payment system.
The architecture separates offline execution from online verification and settlement, allowing payment systems to maintain control over risk, liquidity, and governance even when connectivity or central services are unavailable. Offline payments therefore remain part of the same payment system, not a parallel one.
At the core of the solution is a clear architectural separation:
• Layer-1 consists of the underlying payment system, including native ledgers, settlement engines, liquidity management, monetary controls, and regulatory oversight.
• Layer-2 provides governed offline capability, including shared rules, protocols, and mechanisms for executing payments offline and reconciling them before settlement.
More specifically, the architecture deliberately separates:
• Offline execution and acceptance locally, performed by offline wallets and offline terminals
• Offline coordination, verification, and conversion in backend components
• Online settlement and ledger authority in the underlying payment system
Offline payment instructions follow shared Layer-2 rules and can be executed without online connectivity. Reservations of funds, ledger authority, and final settlement always remain in Layer-1. By operating as a Layer-2 extension rather than modifying Layer-1 systems, offline capability can be introduced without fragmenting settlement, duplicating ledgers, redefining responsibilities, or creating parallel forms of money.
Offline payments are separated from settlement by design.
Offline payments are executed locally by secure offline wallets within isolated runtimes that enforce balance and risk rules. Offline execution is controlled by locally enforced limits and rules rather than by transferring monetary value offline. Local enforcement includes:
• Spending limits and reservation enforcement
• Prevention of double spending
• Sequencing and expiry rules for offline transactions
• Network-defined risk constraints
These controls are derived from reservation state managed online by the underlying payment system and are synchronised to devices before loss of connectivity. Because limits are enforced locally and derived from online reservation state, offline execution remains controlled and predictable, allowing payments to continue without accumulating uncontrolled credit exposure or moving value outside the regulated system. Offline execution does not imply trust in devices themselves, but trust in the rules enforced within isolated runtimes. Offline security relies on locally enforced rules, not device assumptions.
Offline payment instructions are generated and signed inside an isolated runtime, which forms the enforcement boundary of the offline system. This boundary protects cryptographic keys, local state, and rule enforcement even when devices are fully disconnected. The isolated runtime ensures that balance and risk rules, sequencing, and expiry constraints cannot be bypassed, including across multiple consecutive offline payments executed without intermittent connectivity. Offline payment instructions are only signed when all balance and risk rules are satisfied.
Isolated runtimes may be implemented using hardware-based secure elements or software-based virtual secure elements. Crunchfish’s patents cover both approaches, allowing scalable deployment across devices and platforms while preserving the same enforcement boundaries and security properties.
To preserve the integrity of offline execution under all conditions, offline wallets implement rollback protection as a core enforcement mechanism. The local offline state, including balance and reservation state, risk counters, sequencing information, and executed payment instructions, is stored in encrypted form and bound to the isolated runtime. Attempts to revert the device to a previous state, restore earlier snapshots, or otherwise manipulate local state are detected and prevented. This ensures that balance spending limits, risk controls, and execution rules remain effective across device restarts, power loss, and extended periods of offline operation, including scenarios where multiple offline payments occur before reconnection.
Offline execution and acceptance are governed by a non-native Layer-2 security protocol that is independent of the underlying payment system’s online security mechanisms. This enables consistent offline behaviour across different payment environments. Offline payment instructions are exchanged locally using transport-agnostic proximity methods such as QR codes, NFC, Bluetooth Low Energy, or combinations thereof. Transport choice does not affect payment semantics, integrity, or verification, as security is bound to the signed instruction rather than to the communication channel. End-to-end instruction integrity is preserved. The instruction is not transformed during acceptance, ensuring that what is executed offline is exactly what is later verified and settled. The same signed offline payment instruction is:
• Generated by the offline wallet during execution
• Verified locally by the receiving offline wallet or offline terminal at acceptance
• Verified again by backend components before settlement
Offline execution relies on trusted client environments that can securely hold cryptographic keys, enforce balance and risk rules, and authenticate payment instructions both offline and online. By anchoring private keys and execution logic within isolated runtimes, the architecture strengthens client authentication and instruction integrity not only during offline operation but also for online payments. Crunchfish’s Trusted Application Protocol (TAP) is one implementation of this trusted-client model, enabling secure, transport-agnostic communication and authenticated instruction exchange across both proximity-based and network-based environments.
Offline payments in a governed payment system must not shift settlement risk to payees. If merchants, agents, or receiving users are expected to absorb settlement uncertainty, adoption will suffer, particularly for small merchants and participants with tight cash cycles. For offline payments to scale, payees must receive predictable settlement outcomes once systems recover. In Crunchfish’s offline payment architecture, risk is borne by the issuer of the offline wallet, not by the payee. Offline payment instructions are executed under issuer-defined limits and guarantees, enforced through isolated runtime environments. If an offline payment instruction is valid under system rules, settlement succeeds. If limits are violated or inconsistencies are detected, the resulting exposure is absorbed by the issuer and managed through established recovery mechanisms when connectivity returns.
Issuers assume settlement risk, not payees.
In a baseline deferred offline scenario, where a payer reserves funds and executes an offline payment, settlement risk does not shift to the payee. If the payer has exceeded limits or violated rules, this may result in a temporary negative balance at the issuer, effectively a micro-loan or overdraft. This exposure is managed by the issuer, which retains recourse against its customer through normal enforcement and recovery processes.
When consecutive offline payments are permitted, issuer-managed credit becomes an explicit design element rather than an implicit side effect. For example, a payee that has received an offline payment may itself execute an offline payment before reconnecting. If the final recipient reconnects first, settlement proceeds under issuer guarantees, potentially creating a temporary negative balance at the intermediate issuer. This exposure is not pushed back to the original payer and is not borne by the final recipient. Instead, it is treated as a controlled, time-limited credit managed by the issuer under balance and risk rules. This is a deliberate architectural choice. Credit is introduced only when explicitly allowed by policy, enforced through strict limits, sequencing, expiry, and verification rules. Ledger authority remains intact, settlement discipline is preserved, and merchant confidence is maintained without asserting device-level finality or creating parallel forms of money.
Offline exposure is explicit, bounded, and policy-controlled.
Offline backend components coordinate the transition from offline execution to online settlement when connectivity is available. These components support functions such as:
• Onboarding and configuration of offline wallets and offline terminals
• Certificate management
• Distribution of balance and risk rules
• Synchronisation of offline state
• Verification of signed Layer-2 payment instructions
• Conversion of verified Layer-2 instructions into native Layer-1 payment instructions
• Enforcement of system-level rules prior to settlement
Conversion to native payment instructions occurs only after synchronisation and verification, ensuring that settlement in the underlying payment system reflects only valid and authorised offline execution, including sequences of offline payments executed during extended outages.
Depending on governance and deployment choices, backend components may reside at payment network level, bank or regulated-entity level, or application backend level, while remaining subject to the authority of the underlying payment system. This flexibility allows offline capability to be introduced without imposing a single operational topology.
Offline capability is governed through shared Layer-2 protocols, trust frameworks, and certification requirements defined by the payment system or network operator. Trust is enforced through payment-system-governed public key infrastructure (PKI), which binds secure offline wallets, offline terminals, and backend components to interoperable Layer-2 rules. This enables deterministic verification, controlled participation, and revocation where required.
Spending-side controls enforced by offline wallets and acceptance-side controls enforced by receive-only offline terminals are governed separately under system-defined policies. Certification ensures behavioural and security compliance with shared Layer-2 rules, rather than reliance on vendor-specific implementations. These mechanisms enable interoperable offline payment capability across multiple wallets, terminals, and providers, allowing system-wide deployment without bilateral agreements or fragmentation within or across payment ecosystems.
Backend components reconcile offline execution. They do not replace settlement systems.
Offline execution reduces reliance on continuous online transaction processing and, as a result, limits unnecessary exposure of transaction data during normal use. Because payments can be executed locally, transaction details do not need to be transmitted or processed centrally at the time of payment. The timing, scope, and granularity of information revealed during subsequent verification and settlement are defined by payment system policy and governance, rather than being dictated by technical constraints at execution time.
Privacy outcomes are policy decisions, not technical side effects.
Where regulators require reconciliation of offline transactions for AML/CFT purposes, the architectural choice of offline mode has important privacy implications. Immediate offline models, which assert device-level finality, typically require the creation of a dedicated reconciliation mechanism to collect, aggregate, and reconstruct offline transaction histories after the fact. This introduces an adjunct, centralised processing path outside normal settlement flows and can increase privacy risk by concentrating data that would otherwise remain distributed. Deferred, system-governed offline models reconcile transactions at settlement within the existing payment system, allowing established AML/CFT controls and supervisory processes to be reused for offline transactions in the same way as for online payments. This avoids the need for a separate reconciliation system and limits the expansion of the privacy surface. In regulated contexts, this means that deferred offline execution can be more privacy-preserving in practice, not by reducing oversight, but by avoiding new centralised data aggregation beyond what already exists for online payments.
Crunchfish’s architecture supports a range of privacy configurations, reflecting different policy choices. Offline payments can be designed to provide the same level of privacy as online payments, ensuring continuity of regulatory treatment, auditability, and AML/CFT controls across both online and offline operation. Where permitted by policy, the architecture can also support stronger privacy or cash-like anonymity for offline payments. Such configurations intentionally limit or defer the availability of identifying information and may reduce the effectiveness of AML/CFT controls. These trade-offs are explicit policy decisions, governed at system level rather than embedded in devices or applications.
Privacy outcomes are enforced through architecture and governance, not through obscurity or fragmentation. Offline execution does not rely on hidden data flows, undocumented behaviour, or device-specific secrecy. Instead, privacy characteristics are determined by system-defined rules applied consistently across wallets, terminals, backend components, and settlement processes, ensuring predictable behaviour and regulatory clarity.
Crunchfish’s intellectual property protects the Layer-2 architecture and interaction model that enables governed offline payments. Core intellectual property protects the architectural approach, including locally enforced spending controls (including consecutive offline payments), integrity-preserving instruction flows, backend coordination and conversion mechanisms, interoperability models, privacy-preserving configurations, and governance-enforced security. The patents do not protect specific offline wallets, terminals, or user interfaces. This ensures that offline capability can be deployed openly and competitively, supporting multiple offline wallet implementations and acceptance devices while preserving architectural integrity, controlled risk, and system-level governance.
The offline architecture is protected, not the implementation.
Digital payments have become critical public infrastructure and, in many jurisdictions, an integral part of the monetary system. Most digital payment arrangements, however, depend on continuous connectivity and the availability of central services. When networks, backend platforms, or operational systems are disrupted, the ability to make and receive payments can cease. Offline payment capability is therefore not a convenience feature but a resilience requirement for payment systems that are expected to function during outages, crises, and exceptional conditions.
Offline payments are not new, but existing approaches involve structural trade-offs:
• Immediate offline models move value onto devices or rely on trusted hardware to provide device-level finality. While such approaches can enable local continuity, they raise challenges related to monetary integrity, governance, recovery, and system-wide scalability, and may introduce parallel representations of money.
• Deferred offline models, commonly used in card networks, allow offline acceptance by deferring authorisation until connectivity is restored. Settlement is issuer-backed, but risk exposure is managed within scheme-specific limits that are not always visible or governable at system level. These approaches typically restore availability by weakening predictability or constraining scalability within defined network boundaries.
Crunchfish enables offline payments as signed payment instructions executed offline but verified and settled within existing payment systems. Offline execution takes place under locally enforced balance and risk rules, without moving monetary value offline or creating independent stores of value. All transactions are verified before settlement, and ledger authority, liquidity management, and settlement finality remain unchanged. Offline capability operates as a governed Layer-2 extension above existing payment systems, ensuring that offline payments remain part of the same monetary system rather than forming a parallel one.
Offline acceptance must not shift settlement risk to merchants, agents, or receiving users. In Crunchfish’s offline architecture, payees receive predictable settlement outcomes under the authority of the payment system, while risk is borne by issuers of offline wallets under explicit guarantees. Where consecutive offline payments are permitted, temporary credit may arise. This credit is issuer-managed, bounded, time-limited, and subject to policy control. Monetary authority and settlement discipline are preserved, and device-level finality is not asserted.
Offline capability is governed at payment-system level through shared rules, certification, and trust frameworks defined by the system operator. Participation, behaviour, and risk limits are controlled through policy rather than through devices, bilateral agreements, or vendor-specific implementations. Privacy outcomes are likewise policy decisions rather than technical side effects. Offline payments can be designed to provide the same level of privacy as online payments, or stronger privacy where permitted, without weakening supervisory oversight or creating parallel forms of money. By reconciling offline transactions within existing settlement and supervisory processes, deferred offline execution avoids the need for a separate, adjunct centralised data aggregation system, thereby limiting the expansion of the privacy surface.
In short, Crunchfish enables offline payments as a governed extension of existing payment systems, preserving monetary authority, settlement discipline, and regulatory control.
The Technology & IP section describes the architectural foundations and mechanisms used to deliver governed offline payments. For readers seeking deeper analysis of design trade-offs, security considerations, and ecosystem implications, Crunchfish’s whitepapers explore these topics in greater detail.
