> For the complete documentation index, see [llms.txt](https://docs.nearby.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nearby.finance/protocol-layers/offlinepay-settlement-layer.md). # OfflinePay (Settlement Layer) ### A Settlement Layer for Disconnected Environments OfflinePay is the settlement layer of Nearby Protocol. It enables users to transfer stablecoin value without requiring active internet connectivity at the time of transaction. Instead of relying on real-time blockchain interaction, OfflinePay allows value to be exchanged locally between devices and later reconciled on-chain once connectivity is restored. This makes it possible to conduct financial transactions in environments where traditional payment systems are unavailable or unreliable. *** ### Core Design Principle OfflinePay is built on a fundamental separation: * **Transaction execution happens locally** * **Final settlement happens globally** This separation allows users to exchange value immediately, while preserving the ability to enforce global correctness later through reconciliation. *** ### Supported Assets At launch, OfflinePay supports: * USDC * USDT These assets are represented as digitally signed settlement units that can be transferred between devices in offline environments. All balances are ultimately backed and settled on-chain during reconciliation. *** ### Offline Payment Notes The core unit of OfflinePay is the **Offline Payment Note**. A note represents a transferable unit of value that can be: * Created during deposit or issuance * Held locally on a device * Transferred peer-to-peer * Split into smaller units * Recombined during settlement Each note contains: * Value amount * Ownership information (public key) * Unique identifier * Cryptographic signature * Integrity metadata Notes are not global ledger entries during offline execution. They exist as locally verifiable cryptographic objects. *** ### Transaction Model An OfflinePay transaction transfers ownership of one or more payment notes between devices. Each transaction includes: #### Inputs Existing notes being spent by the sender. #### Outputs New notes assigned to the recipient. #### Authorization A cryptographic signature from the sender proving ownership and approval of the transfer. All transactions must preserve value: Total inputs = Total outputs This ensures that no value is created or destroyed during offline execution. *** ### Local Validation Before accepting a transaction, the receiving device performs local verification. These checks include: #### 1. Note Authenticity Verification that input notes were originally issued by the OfflinePay system and are not forged. #### 2. Ownership Validation Verification that the transaction is signed by the legitimate owner of the notes being spent. #### 3. Value Conservation Verification that the transaction preserves total value across inputs and outputs. #### 4. Structural Integrity Verification that: * Notes are not double-referenced within a single transaction * Output notes contain valid ownership data * Transaction format is structurally valid If any check fails, the transaction is rejected immediately. *** ### Offline Transfer Mechanisms OfflinePay supports multiple peer-to-peer transfer channels: * QR-based exchange * Bluetooth transmission * NFC-based transfer * Local mesh relay (via Nearby Mesh) These mechanisms allow transactions to occur in environments without internet access. *** ### Witness Network OfflinePay introduces an optional witness layer for transaction observation. A witness is a nearby device that observes a transaction and optionally signs an attestation confirming: * That a transaction occurred * That it was seen within a specific time window * That participating devices were physically present Witnesses do not validate transaction correctness. Their role is purely evidentiary. Witness attestations are later used during reconciliation to provide additional context in case of conflicting transaction histories. *** ### Absence of Real-Time Global Uniqueness During offline execution, OfflinePay does not enforce global uniqueness of note consumption. This means: * A note may be spent in multiple offline environments simultaneously * Conflicting histories may exist temporarily across devices This is a deliberate design choice to preserve offline functionality without requiring constant connectivity. Global correctness is enforced later during reconciliation. *** ### Reconciliation and Final Settlement When devices reconnect to the network, OfflinePay enters the reconciliation phase. During this process: 1. All locally generated transaction histories are submitted 2. The system aggregates and compares transaction states 3. Conflicts are detected deterministically 4. Invalid or double-spent notes are identified 5. Final valid state is computed Once reconciliation is complete, transactions are settled on-chain on Base. *** ### Conflict Resolution Model If conflicting transactions are detected (e.g., double spending of the same note), the system applies deterministic resolution rules. These rules may consider: * Timestamp ordering (where applicable) * Witness attestations * Transaction propagation history * Cryptographic validity proofs The goal is to ensure eventual consistency while maintaining offline usability. *** ### Witness-Informed Dispute Handling Witness attestations play an important role during conflict resolution. If multiple conflicting histories exist, witness data can help: * Validate which transactions were observed in real-world conditions * Provide contextual evidence of transaction order * Support probabilistic or rule-based resolution mechanisms Witnesses may be rewarded in $NEARBY for contributing valid attestations. *** ### Security Model OfflinePay is designed for adversarial environments where: * Devices may attempt to double spend * Transactions may be delayed or replayed * Connectivity is intermittent or unavailable Security is achieved through: * Cryptographic ownership validation * Local integrity checks * Post-hoc global reconciliation * Witness-based observability * On-chain final settlement guarantees While offline execution is flexible, final settlement is strictly enforced at the protocol level. *** ### Integration with Nearby Protocol OfflinePay is tightly integrated with the rest of the Nearby ecosystem. It relies on: #### Proof of Location For optional geographic constraints on transactions or participation. #### Nearby Mesh For peer-to-peer transaction propagation in local environments. Together, these layers enable: * Offline commerce * Event-based payments * Localized economies * Emergency financial coordination * Connectivity-independent value exchange *** ### From Connectivity to Continuity Traditional payment systems assume continuous connectivity to function. OfflinePay introduces a different model: Transactions can begin, continue and propagate without connectivity and are finalized once the network becomes available. This creates continuity of economic activity across disconnected environments. The result is a settlement layer that operates across the full spectrum of connectivity conditions, from fully online to completely offline. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nearby.finance/protocol-layers/offlinepay-settlement-layer.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.