GhostPay Mesh: A Cryptographic Protocol for Offline-First Value Transfer

GhostPay Research — AstroPayments Labs

Version 2.0 • January 2025

1. Problem Statement

1.1 The Connectivity Gap

Despite rapid growth in mobile payments globally, a significant portion of the world’s population lacks reliable internet connectivity. In Brazil alone, 36 million people have limited or no internet access (IBGE, 2023). The problem is compounded during large-scale events, natural disasters, and in rural areas where infrastructure is sparse.

Existing digital payment solutions — Pix, credit cards, mobile wallets — all require real-time connectivity to a centralized backend. When the network is unavailable, these systems fail entirely, forcing users back to physical cash with all its associated risks and inefficiencies.

1.2 Limitations of Current Approaches

• Mobile money (M-Pesa model): Requires SMS connectivity and centralized operator. Not fully offline-capable.
• Stored-value cards: Limited to issuing institution, no peer-to-peer transfers, no cryptographic verification.
• Blockchain-based solutions: Require network access for transaction confirmation. Lightning Network requires channel state management that depends on connectivity.
• Physical cash: Susceptible to theft, counterfeiting, and lacks auditability. Distribution is expensive in remote areas.

1.3 Requirements for an Offline-First Solution

An effective offline payment protocol must satisfy the following requirements:

1. Offline creation: New payment instruments must be creatable without network access.
2. Offline transfer: Instruments must be transferable between parties using only local communication (BLE, NFC, QR).
3. Verifiability: Recipients must be able to verify instrument validity without contacting a server.
4. Double-spend protection: The system must prevent or detect double-spending, even during extended offline periods.
5. Eventual settlement: Instruments must be redeemable for real monetary value when connectivity returns.
6. Privacy: Minimal personal data collection. No KYC for small-value transactions.
7. Compact representation: Instruments must be small enough to transfer via QR code (~3KB limit).

2. Solution Architecture

2.1 Cryptographic Liquidity Promises (PLCs)

GhostPay Mesh introduces Cryptographic Liquidity Promises (PLCs) as the fundamental unit of value transfer. A PLC is a digitally signed instrument in which an issuer commits to settling a specific monetary amount through a traditional payment rail. Unlike bearer instruments, PLCs carry a cryptographic chain of custody that enables offline verification.

A PLC is to digital payments what a signed check is to banking — a commitment backed by the issuer’s reputation and cryptographic identity, transferable without the issuer’s direct involvement.

2.2 System Components

graph TB
    subgraph "Offline Layer"
        A[Device A
Issuer] -->|BLE/NFC/QR| B[Device B
Bearer]
        B -->|BLE/NFC/QR| C[Device C
Bearer]
        C -->|BLE/NFC/QR| D[Device D
Bearer]
    end

    subgraph "Settlement Layer"
        D -->|Internet| E[Settlement Service]
        E --> F[Pix]
        E --> G[Boleto]
        E --> H[On-chain]
    end

    subgraph "Verification"
        I[Global Ledger
Double-spend detection]
        E --> I
    end
            

The architecture consists of three layers:

1. Offline Layer: Devices create, verify, and transfer PLCs using local peer-to-peer communication. No server interaction required.
2. Settlement Layer: When connectivity is available, PLCs are submitted for settlement through traditional payment rails.
3. Verification Layer: A global ledger tracks settled PLCs to prevent double-spending at the settlement boundary.

2.3 Design Principles

• Offline-first: Every operation that can be performed offline, is performed offline. Connectivity is required only for settlement.
• Cryptographic trust: Trust is established through mathematical proofs (signatures, hashes) rather than institutional authority.
• Privacy by default: The protocol collects zero personal data. Identity is based solely on pseudonymous public keys.
• Compact and efficient: PLC payloads are optimized to fit within QR code capacity (~2.5KB typical).
• Regulatory compatible: Settlement through regulated payment rails (Pix, Boleto) ensures compatibility with existing financial regulation.

3. Protocol Design

3.1 PLC Issuance

PLC issuance is a local operation performed entirely on the issuer’s device. The issuer specifies an amount and currency, and the device generates a cryptographic commitment binding these values to the issuer’s identity.

The commitment hash H is computed as:

H = SHA-256(id || amount || currency || issuer_pubkey || created_at || expires_at || nonce)

The issuer then signs H with their Ed25519 private key:

σ = Ed25519.sign(issuer_privkey, H)

This produces a PLC with a verifiable binding between the committed amount and the issuer’s identity.

3.2 Transfer Protocol

Transfers append a new record to the PLC’s transfer_chain. Each transfer record contains:

• from_pubkey: Current bearer’s public key
• to_pubkey: Recipient’s public key
• nonce: Cryptographically random 128-bit value
• timestamp: Transfer time (local clock)
• prev_hash: Hash of the previous transfer record (or commitment hash for the first transfer)
• signature: Ed25519.sign(from_privkey, to_pubkey || nonce || timestamp || prev_hash)

The chain structure ensures that each transfer is cryptographically linked to all previous transfers, creating an append-only log that prevents retroactive modification.

3.3 Verification Algorithm

Upon receiving a PLC, the recipient executes the following verification algorithm (all operations are local):

1. Recompute H’ = SHA-256(id || amount || currency || issuer_pubkey || created_at || expires_at || nonce). Verify H’ == commitment_hash.
2. Verify Ed25519.verify(issuer_pubkey, commitment_hash, signature).
3. For each transfer T[i] in the chain:
   • If i == 0: verify T[i].from_pubkey == issuer_pubkey and T[i].prev_hash == commitment_hash.
   • If i > 0: verify T[i].from_pubkey == T[i-1].to_pubkey and T[i].prev_hash == SHA-256(T[i-1]).
   • Verify Ed25519.verify(T[i].from_pubkey, T[i].to_pubkey || T[i].nonce || T[i].timestamp || T[i].prev_hash, T[i].signature).
4. Verify expires_at > current_time (with configurable clock tolerance).
5. Verify the latest T[n].to_pubkey matches the expected sender.

3.4 Settlement

Settlement is the only protocol operation requiring internet connectivity. The current bearer submits the complete PLC (including transfer chain) to the settlement service, which:

1. Performs the full verification algorithm described in Section 3.3.
2. Checks the PLC ID against the global ledger for prior settlement attempts.
3. If the PLC has not been previously settled, initiates payment through the selected rail.
4. Records the settlement in the global ledger to prevent future double-spend.

4. Security Analysis

4.1 Double-Spend Resistance

The protocol provides two layers of double-spend protection:

Offline layer: An attacker who copies a PLC and attempts to transfer it to two different recipients would need to fork the transfer chain. However, both forks would share the same prev_hash, meaning only the first settlement attempt succeeds. The second fork is detected and rejected at settlement time.

Settlement layer: The global ledger maintains an index of all settled PLC IDs. Any PLC submitted for settlement is checked against this index. Duplicate settlements are rejected with a 409 Conflict response containing the original settlement timestamp.

4.2 Forgery Resistance

Creating a valid PLC requires possession of an Ed25519 private key. Under the standard model, the probability of forging an Ed25519 signature without the private key is negligible (2-128). An attacker cannot:

• Create a PLC that appears to be issued by another device
• Modify the amount or currency of an existing PLC (invalidates the commitment hash)
• Insert, remove, or reorder entries in the transfer chain (invalidates chain hashes and signatures)

4.3 Replay Resistance

Each transfer includes a unique 128-bit nonce. Devices maintain a local bloom filter of recently seen nonces. The probability of nonce collision is < 2-64 for up to 232 transfers (birthday bound). At settlement time, the backend performs exact nonce deduplication against the global ledger.

4.4 Privacy Properties

The protocol provides the following privacy properties:

• Pseudonymity: Parties are identified only by public keys, which are unlinkable without additional information.
• Transfer privacy: The settlement service sees the full transfer chain, but intermediate transfer data is not persisted after settlement verification.
• Amount privacy: PLC amounts are visible to all parties in the chain (required for verification). Future versions may explore zero-knowledge amount proofs.

4.5 Failure Modes

5. Use Cases

5.1 Rural Communities

In communities with limited internet infrastructure, GhostPay Mesh enables digital payments between residents, local merchants, and service providers. A community leader or local bank agent can serve as a settlement hub, periodically connecting to the internet to settle accumulated PLCs.

5.2 Large-Scale Events

Festivals, concerts, and sporting events often overwhelm cellular infrastructure. GhostPay Mesh enables attendees to pay vendors, split bills, and transfer funds using BLE mesh networking, with settlements occurring after the event when connectivity normalizes.

5.3 Disaster Relief

During natural disasters when infrastructure is damaged, GhostPay Mesh enables the distribution and transfer of relief funds without requiring functional payment infrastructure. Aid organizations can issue PLCs to beneficiaries, who can transfer them to merchants for essential goods.

5.4 Cross-Border Remittances

Workers in connectivity-poor areas can receive PLCs from family members abroad and redeem them through local settlement agents. The on-chain settlement rail enables cross-border value transfer without traditional correspondent banking relationships.

5.5 Merchant Payments

Small merchants in areas with unreliable connectivity can accept PLC payments throughout the day and settle them in batch when internet access is available, reducing dependency on real-time payment infrastructure.

6. Roadmap

7. Conclusion

GhostPay Mesh addresses a critical gap in the digital payments landscape: the inability to transact when connectivity is unavailable. By combining well-established cryptographic primitives with a novel transfer chain mechanism, the protocol enables secure, verifiable, offline value transfer while maintaining compatibility with existing financial infrastructure through multi-rail settlement.

The protocol’s security properties — forgery resistance, double-spend detection, replay protection — are grounded in the computational hardness of Ed25519 and SHA-256, not in trust relationships or institutional guarantees. This makes GhostPay Mesh resilient to the very infrastructure failures it is designed to operate through.

The privacy-by-design approach, requiring zero personal data and using pseudonymous public keys, positions the protocol favorably against increasingly stringent data protection regulations while serving the unbanked populations who are often excluded by KYC requirements.

We believe GhostPay Mesh represents a meaningful step toward universal financial inclusion — a world where the ability to make a digital payment is not contingent on the availability of an internet connection.

Payments should work everywhere. Not just where the signal reaches.

References

1. Bernstein, D.J. et al. “High-speed high-security signatures.” Journal of Cryptographic Engineering, 2012.
2. IBGE. “Pesquisa Nacional por Amostra de Domicilios — Acesso à Internet.” 2023.
3. Banco Central do Brasil. “Pix: Brazilian Instant Payment System Technical Specification.” 2020.
4. Josefsson, S. & Liusvaara, I. “Edwards-Curve Digital Signature Algorithm (EdDSA).” RFC 8032, 2017.
5. Arciszewski, S. “XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305.” Internet-Draft, 2020.
6. Biryukov, A. et al. “Argon2: the memory-hard function for password hashing and other applications.” 2017.
7. Nakamoto, S. “Bitcoin: A Peer-to-Peer Electronic Cash System.” 2008.
8. Yakovenko, A. “Solana: A new architecture for a high performance blockchain.” 2018.