> 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/architecture/security-model.md). # Security Model Nearby Protocol is designed for adversarial, real-world environments where devices may be offline, partially connected or operating under constrained trust assumptions. The system combines zero-knowledge cryptography, device attestation, mesh networking and delayed settlement to maintain security across all three layers: * Proof of Location * Nearby Mesh * OfflinePay This document outlines the core security assumptions, guarantees and known limitations of the protocol. *** ### Security Design Principles Nearby Protocol is built around four foundational principles: #### 1. Cryptographic Verifiability Whenever possible, correctness is enforced through cryptographic proofs rather than trust in centralized entities. #### 2. Device-Level Integrity Security begins at the device level using trusted execution environments and hardware-backed attestation. #### 3. Probabilistic Trust in Offline Environments During offline operation, the system accepts that global consistency cannot be enforced in real time and instead relies on local validation and delayed reconciliation. #### 4. Eventual Consistency Final correctness is always enforced at the settlement layer once connectivity is restored. *** ### Threat Model Overview Nearby Protocol assumes the presence of the following adversaries: * Malicious end-user devices attempting to spoof location or transactions * Devices attempting to double-spend offline assets * Sybil attackers generating fake nodes or witnesses * Network-level adversaries disrupting mesh communication * Partial observability environments where data is delayed or fragmented The protocol is not designed to prevent all malicious behavior in real time. Instead, it ensures that malicious activity becomes detectable and economically punishable during reconciliation. *** ### Proof of Location Security #### Trust Assumptions Proof of Location relies on: * Trusted Execution Environments (TEE) * Device attestation mechanisms * Multi-signal location validation * zkSNARK-based verification circuits #### Primary Risks **1. GPS or Sensor Spoofing** Mitigated through: * Cross-signal consistency checks * Hardware-backed attestation * Runtime integrity validation in secure environments **2. Software Tampering** Mitigated through: * Execution inside trusted environments * Attestation of application state before proof generation **3. Colluding Devices** Partially mitigated through: * Witness layer observations * Geographic distribution constraints * Economic penalties during validation #### Limitations * Absolute prevention of advanced physical spoofing is not guaranteed * Security increases with hardware trust quality and network density *** ### Nearby Mesh Security #### Threat Model Mesh networks operate in open environments where: * Nodes may drop or modify messages * Routing paths may be unpredictable * Participants may behave maliciously or unpredictably #### Mitigations * End-to-end encryption for message payloads * Message integrity checks using cryptographic signatures * Local filtering of duplicate or malformed packets * Ephemeral network participation (reduces long-term tracking risks) #### Limitations * Metadata leakage (e.g., propagation patterns) may still exist * Complete anonymity is not guaranteed in high-density networks with adversarial observers Nearby Mesh prioritizes resilience and local functionality over perfect anonymity guarantees. *** ### OfflinePay Security Model #### Core Challenge OfflinePay operates in environments without real-time global consensus. This creates a fundamental risk: * The same payment note may be spent in multiple offline environments before reconciliation. #### Mitigation Strategy OfflinePay resolves this through a layered approach: **1. Cryptographic Ownership Validation** Every transaction requires a valid signature from the note owner. **2. Local Validation Rules** Devices enforce: * Value conservation * Note authenticity * Structural transaction integrity **3. Witness Attestations** Optional witnesses provide observational evidence of transaction events, strengthening reconciliation outcomes. **4. Post-Hoc Global Reconciliation** Once connectivity is restored: * All transaction histories are submitted * Conflicts are detected deterministically * Double-spends are resolved through protocol rules * Final state is committed on Base #### Finality Model Offline transactions are: * **Locally valid immediately** * **Globally final only after reconciliation** *** ### Double-Spend Risk OfflinePay explicitly allows temporary double-spend risk during offline operation. This is not a bug, it is a design choice required for offline functionality. Risk is controlled through: * Limited offline exposure windows * Economic penalties during reconciliation * Witness-assisted verification * Traceability of conflicting histories The system ensures that double-spending cannot persist indefinitely without detection. *** ### Witness Security Model Witnesses provide an optional observational layer across both Proof of Location and OfflinePay. #### Trust Assumptions Witnesses are assumed to be: * Independent devices * Opportunistic observers * Not required to be fully honest individually #### Security Function Witnesses do NOT: * Validate cryptographic correctness * Authorize transactions * Control settlement logic Witnesses DO: * Record event observations * Provide attestation signatures * Contribute auxiliary evidence during reconciliation #### Risk Model * Individual witnesses can be malicious or incorrect * Security emerges from aggregation across multiple witnesses *** ### Sybil Resistance Nearby Protocol does not rely on a single global identity system. Instead, Sybil resistance is achieved through: * Device attestation requirements * Hardware-bound proof generation * Economic cost of participation (staking/rewards dilution) * Geographic distribution constraints in Proof of Location This makes large-scale fake participation economically and technically expensive. *** ### Network-Level Attacks #### Message Manipulation Mitigated through: * Cryptographic signatures * Integrity verification at the device level #### Routing Disruption Mitigated through: * Multi-path message propagation * Redundant relay design * Local fallback routing #### Partitioning Attacks Accepted as a natural condition of mesh networks. The system is designed to operate under partitioned network states and recover during reconnection. *** ### Key Limitations Nearby Protocol does not attempt to solve all security problems in real time. Known limitations include: * Offline double-spend cannot be prevented, only resolved later * Metadata leakage may exist in mesh environments * Full anonymity is not guaranteed under global adversarial observation * Device-level compromise weakens security guarantees * Security depends on hardware trust assumptions (TEE reliability) These limitations are intentional trade-offs to enable offline and decentralized operation. *** ### Security Philosophy Nearby Protocol does not aim for absolute security under all conditions. Instead, it aims for: * Strong cryptographic guarantees where possible * Probabilistic safety in offline environments * Economic enforceability during reconciliation * Transparent and auditable system behavior Security is treated as a layered system rather than a single point of trust. *** ### Final Statement Nearby Protocol is designed to remain functional under real-world constraints where perfect connectivity, perfect trust and perfect synchronization do not exist. Its security model reflects this reality by combining cryptographic verification, hardware attestation, distributed observation and eventual on-chain settlement into a unified system. The goal is not to eliminate all risk, but to ensure that risk is measurable, bounded and economically enforceable. --- # 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/architecture/security-model.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.