Back to Home
Protocol Whitepaper

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

Version 1.0.0
Date March 2025
Authors GhostPay Mesh Team
Status Draft — Under Review
Download PDF (Coming Soon)
01

Abstract

We present GhostPay Mesh, a cryptographic protocol enabling offline-first value transfer through Payment Letter of Credit (PLC) instruments. By combining Ed25519 digital signatures, XChaCha20-Poly1305 authenticated encryption, and SHA-256 commitment schemes, the protocol allows creation, transfer, and eventual settlement of payment promises without requiring network connectivity. We demonstrate that the protocol maintains security guarantees equivalent to online payment systems while operating in fully disconnected environments, with a novel time-bounded commitment mechanism that prevents double-spending upon reconnection.

02

Introduction

The global payment infrastructure relies on persistent network connectivity for transaction authorization, clearing, and settlement. This dependency creates a critical failure mode: when connectivity is unavailable — whether due to network congestion at events, infrastructure failures, geographic remoteness, or deliberate censorship — economic activity stops.

Current solutions to offline payments are limited to stored-value cards (no programmability), SMS-based systems (requires cellular), or deferred settlement with no cryptographic guarantees. None provide a general-purpose, cryptographically secure mechanism for offline value transfer.

GhostPay Mesh addresses this gap by introducing the Payment Letter of Credit (PLC) — a cryptographic instrument that encapsulates a payment promise with provable authenticity, integrity guarantees, and time-bounded validity. PLCs can be created, transferred, and verified entirely offline, with deterministic settlement when connectivity is restored.

03

Protocol Overview

The GhostPay Mesh protocol operates in three phases: Promise Creation, Offline Transfer, and Network Settlement. Each phase is designed to function independently, allowing participants to complete their portion without knowledge of the others' state.

PLC Lifecycle

Create PLC
Sign (Ed25519)
Encrypt (XChaCha20)
Transfer (QR/NFC/BLE)
Settle

A PLC contains: the amount, currency, issuer public key, recipient identifier, creation timestamp, expiration (TTL), a nonce, and a digital signature covering all fields. The compact binary encoding allows PLCs to fit within QR code capacity limits (approximately 4,296 alphanumeric characters).

Device binding is achieved through hardware-backed key storage (Secure Enclave on iOS, StrongBox on Android), ensuring private keys never leave the device. This prevents PLC forgery even if the device's application layer is compromised.

04

Cryptographic Design

The protocol employs three cryptographic primitives, each chosen for specific security properties and performance characteristics in resource-constrained mobile environments:

Ed25519 (EdDSA over Curve25519): Used for digital signatures on PLC instruments. Ed25519 provides 128-bit security, deterministic signatures (no random number generator dependency — critical for offline devices), and fast verification (approximately 71,000 signatures/second on modern mobile hardware).

sig = Ed25519_Sign(sk, H(amount || currency || issuer_pk || recipient || timestamp || ttl || nonce))

XChaCha20-Poly1305: Used for authenticated encryption of PLC payloads during transfer. The extended nonce (192-bit) eliminates nonce collision risks in offline environments where coordinated nonce management is impossible. Poly1305 MAC provides authentication, preventing modification of encrypted PLCs in transit.

ciphertext = XChaCha20-Poly1305_Encrypt(shared_key, nonce_192, plc_payload, aad)

SHA-256 Commitment Scheme: Used to create binding commitments that are published to the settlement network before the PLC is transferred. This enables double-spend detection: if two PLCs share the same commitment hash, the settlement system rejects the later submission.

commitment = SHA-256(plc_id || amount || issuer_pk || nonce)
05

Offline Settlement

The settlement process uses a conflict-free replicated data type (CRDT) approach to merge transaction states from multiple offline devices. When devices reconnect, they submit their local transaction logs to the settlement network.

Settlement Flow

Reconnect
Submit Log
Verify Signatures
Check Commitments
Finalize

The settlement algorithm processes submitted PLCs in timestamp order, verifying each signature and checking commitments against the global ledger. PLCs with valid signatures but duplicate commitments are flagged for dispute resolution. The time-bounded nature of PLCs (default 24-hour TTL) limits the window for potential conflicts.

For high-value transactions, a pre-commitment phase can be executed while online: the issuer publishes a commitment hash before going offline, reserving funds in the settlement system. This eliminates double-spend risk entirely at the cost of requiring brief connectivity during issuance.

06

Security Analysis

We analyze the protocol against the following threat model:

07

Use Cases

The protocol enables a broad range of real-world applications:

08

Roadmap

The protocol development follows a phased approach, with each phase building on the security and reliability guarantees of the previous:

09

References

  1. Bernstein, D.J. et al. "High-speed high-security signatures." Journal of Cryptographic Engineering, 2012.
  2. Bernstein, D.J. "The Poly1305-AES message-authentication code." FSE 2005, LNCS 3557.
  3. Arciszewski, S. "XChaCha20-Poly1305 Construction." IETF Draft, 2020.
  4. NIST. "Secure Hash Standard (SHS)." FIPS PUB 180-4, 2015.
  5. Josefsson, S., Liusvaara, I. "Edwards-Curve Digital Signature Algorithm (EdDSA)." RFC 8032, 2017.
  6. Shapiro, M. et al. "Conflict-free Replicated Data Types." SSS 2011, LNCS 6976.
  7. World Bank. "Global Findex Database 2021: Financial Inclusion, Digital Payments, and Resilience." 2022.
  8. GSMA. "State of Mobile Internet Connectivity Report." 2023.