Abstract

1. Introduction

The ambition to replace the global credit card infrastructure with a decentralized alternative has been a recurring goal within the distributed ledger community. Yet every proposed solution has collided with the same architectural wall: consensus mechanisms designed for security and decentralization, not for speed. The Visa network processes approximately 1,700 transactions per second at peak load, with the network's theoretical ceiling considerably higher. No production blockchain architecture has come close to this figure under real-world conditions.

The standard diagnosis is correct: global consensus is slow because it requires agreement across thousands of geographically dispersed nodes before any transaction can be confirmed. Every proposed remedy — sharding by hash range, payment channels, DAG structures, delegated validators — addresses a symptom rather than rethinking the fundamental premise.

This paper proposes a different premise. The vast majority of payment transactions in the physical world occur between parties who are physically close to each other. A person buying a coffee is near the coffee shop. A person paying a street vendor is at the vendor's location. This geographic co-location, historically treated as irrelevant to the consensus model, is a powerful security and efficiency primitive that can be exploited to radically restructure how a distributed payment network achieves agreement.

The ProxCell Protocol is built on this insight. Rather than asking all nodes in the world to agree on every transaction, it asks only the nodes geographically proximate to the transacting parties to form a local consensus. Rather than propagating individual transaction records up through the global hierarchy, it propagates only cryptographically signed net settlement totals, so that the global layer processes a handful of numbers regardless of network-wide transaction volume. Rather than holding all global funds in a single ledger, it distributes fund custodianship across nested geographic layers, isolating the financial impact of any transaction to its geographic scope.

2. Core Insight: Physical Proximity as a Security Primitive

In traditional payment systems, the physical presence of a card at a point-of-sale terminal is already used as a security signal. The ProxCell Protocol extends this principle into the decentralized domain by making physical co-location a first-class cryptographic attestation mechanism.

2.1 The Payment Act as a Co-Location Proof

When two parties execute a ProxCell transaction, the payment is initiated through a direct device-to-device channel: NFC contact, Bluetooth handshake, or a combination of short-range communication methods. This channel cannot be established between devices that are not physically proximate. The handshake produces a mutual co-location attestation signed by both devices — the sender and the receiver confirm to the network that they are in the same physical location at the same moment.

This design has a critical security property: the counterparty in a transaction cannot be an accomplice in falsifying location. A user attempting to claim presence in Singapore while actually being in Rome cannot complete a local payment in Singapore unless there is a real device in Singapore physically touching their device. The payment act, therefore, simultaneously transfers value and certifies the physical location of both parties.

2.2 Cryptographic Location History and Anomaly Detection

Each payment interaction produces a timestamped, mutually signed co-location record. These records accumulate over time, building a cryptographic location history for each account. This history is periodically anchored to the network via a Merkle tree commitment posted at regular intervals. An account showing confirmed payment interactions in two geographically distant locations within a time window shorter than the minimum possible travel time between them is immediately flagged. Detection is automatic, fast, and requires no central authority.

2.3 Progressive Location Trust

A new account with no payment history has no established location profile. As the account participates in transactions, its location profile is built organically. Two or three confirmed co-location events in the same area establish a geographic anchor for the account. The security of location attestation strengthens naturally with usage, without requiring any enrollment step beyond initial account creation.

3. System Architecture

3.1 The Mobile Node Model

Every participant in the ProxCell network runs a node. The node software operates on a standard smartphone. There is no requirement for dedicated hardware, server infrastructure, or continuous availability. Nodes are designed to be launched when needed, to synchronize their local state within a short initialization window, and to be closed when the user is done transacting.

Node participation is voluntary and non-continuous. The network is designed to function correctly even when the majority of nodes are offline, because the active node population in a densely populated area at any given time is sufficient to sustain local consensus. Network density scales naturally with population density and transaction volume: the areas with the highest payment demand are also the areas with the most active devices.

3.2 Geo-Cell Formation and Membership

Geo-cells are the fundamental unit of local consensus in the ProxCell Protocol. A geo-cell is a dynamically formed sub-network of nodes that are geographically proximate to each other. Cells are not predefined administrative boundaries — they are emergent structures that form based on the actual distribution of active nodes at any given time.

Each node participates in multiple geo-cells simultaneously. A node is a member of every geo-cell whose geographic radius includes its current location. Because cells are defined by radius from each member's perspective, the membership sets of different cells overlap substantially. This overlapping membership structure creates redundancy, cross-cell knowledge for fraud detection, and a natural transition mechanism for users who are moving.

Critically, this overlapping membership means that the same transaction may be witnessed by nodes belonging to multiple micro-cells. This has direct implications for how settlement is aggregated upward, as described in Section 3.6.

3.3 Hierarchical Geographic Ledger

The ProxCell Protocol does not maintain a single global ledger of all account balances. Instead, it distributes fund custodianship across a hierarchy of geographic layers. Each layer encapsulates the financial state relevant to its geographic scope. Settlement between accounts within the same layer does not propagate to any higher layer.

The hierarchy consists of six layers, from the global foundation to the consumer micro-cell:

Table 1: ProxCell Protocol geographic settlement hierarchy

When two accounts transact within the same Layer 5 micro-cell, the settlement is entirely local to that cell. No other layer is involved, and no other region of the world is affected. The layer at which a transaction settles is determined by the geographic scope needed to contain both parties: a transaction between two accounts in different city districts of the same metropolitan area settles at Layer 3. A transaction between accounts in two different cities of the same country settles at Layer 2. A transaction between accounts in different countries of the same continent — for example, an Italian user paying a French user — settles at Layer 1. An intercontinental transaction — for example, a payment from Europe to the United States, or from Indonesia to Australia — settles at Layer 0. At each level, only the financial sub-system at that level needs to process the settlement.

3.4 Geographic Fund Distribution and Bucket Isolation

The most significant architectural departure from conventional distributed ledger systems is the geographic distribution of funds themselves. In a traditional blockchain, the full value of the network resides in a single ledger. Every transaction, no matter how local, is a mutation of the global state.

In ProxCell, funds are held in geographic buckets. Each bucket corresponds to a layer in the hierarchy. A transaction between two accounts within the same bucket is settled entirely within that bucket. Nodes in other buckets do not receive, process, or validate the transaction in any form. An attack on the financial state of one geographic bucket cannot propagate to other buckets. The blast radius of any failure is bounded by geography.

When a user travels, their account's active balance migrates gradually through the hierarchy at the pace of natural human movement, which is bounded and predictable. This predictability makes the system robust against attempts to simultaneously operate in multiple distant locations.

3.5 Implementation Notes: Chain Architecture Mapping

The geographic hierarchy described in this paper is technology-agnostic at the conceptual level. However, it maps naturally onto a multi-chain blockchain architecture, and this correspondence provides a concrete implementation path worth describing.

In a multi-chain system, each geographic layer is served by two distinct chain types operating in tandem. A state-archive chain anchors the snapshot of account balances, node registries, and participation records for its geographic scope, updating at infrequent intervals. One or more transaction chains carry the actual payment traffic for that scope at high frequency. The state-archive chain maintains cryptographic references to its transaction chains, and the transaction chains embed references back to the most recent state-archive block, creating a bidirectional cryptographic bond between the two. New nodes joining any layer of the hierarchy can bootstrap by downloading only the most recent state snapshot from the archive chain rather than replaying the full transaction history, enabling any mobile device to become an operational node within seconds of launch.

This multi-chain structure repeats recursively at every level of the geographic hierarchy. The state-archive chain at each level serves as the settlement anchor for the transaction chains below it, propagating finality upward from the micro-cell level to the global layer in a cascade that never requires the entire global network to process an individual consumer transaction.

3.6 Hierarchical Net Settlement and Layered Aggregation

A critical property of the ProxCell architecture, and the mechanism most responsible for its performance characteristics, is that individual transaction data does not propagate upward through the geographic hierarchy. What propagates is a cryptographically signed net settlement total: a single number representing the aggregate flow across all transactions that occurred within a given layer during a settlement period, accompanied by the proof that the local consensus validated it correctly.

The global layer therefore processes exactly as many numbers as there are continents — seven — regardless of whether one million or one billion transactions occurred that day across the network. The continental layer processes country totals. The national layer processes metropolitan region totals. The city district layer processes its micro-cell inputs. The computational load at each layer scales with the number of sub-units below it, not with transaction volume.

3.6.1 The Layer 5 to Layer 4 Special Case: Deduplication

The transition from micro-cell (Layer 5) to city district (Layer 4) is architecturally distinct from all other layer transitions, and for a specific reason: micro-cells overlap.

Because geo-cell membership is radius-based and cells overlap substantially, the same transaction is typically witnessed by nodes belonging to multiple micro-cells simultaneously. A city district cannot simply sum the net totals reported by its micro-cells — this would produce systematic double-counting. Instead, the city district must perform a full deduplication pass over all transaction hashes received from all micro-cells within its boundary. Transactions witnessed by multiple cells are identified by their cryptographic hash and counted exactly once. After deduplication, the city district computes a clean net total for its area and forwards only that total to the metropolitan layer above.

This is the only layer transition where individual transaction hashes travel upward. The city district acts as the deduplication boundary: everything above Layer 4 operates on net totals only. The computational cost of deduplication is real, particularly in high-density urban areas, and the architecture accommodates this in two ways. First, a city can be subdivided into many city districts that each handle a fraction of the deduplication work independently and in parallel. Second, an optional intermediate aggregation layer may be introduced between Layer 5 and Layer 4 to absorb the deduplication workload without altering the settlement logic above it.

3.6.2 Layer 4 to Layer 0: Pure Net Settlement

From the city district level upward, every layer transition is identical in structure. Each layer collects the signed net settlement totals from all sub-units at the layer below, validates the cryptographic signatures, aggregates them into a single net total for its own scope, signs it with the consensus of its own node set, and forwards it to the layer above. No individual transaction data is included. No transaction hashes travel upward. Only signed aggregate numbers move through the upper layers of the hierarchy.

The sole exception to the pure net aggregation model is the individual cross-layer transaction: a single payment between two parties whose accounts reside in geographic sub-trees that share no common layer below the one required to contain both of them. Such transactions are routed directly to the lowest common layer as standalone settlements rather than being bundled into any net batch.

To make this concrete with two examples at different scales. If a user in Rome sends a payment to a user in Milan, both cities belong to the same country but to different metropolitan regions. Their lowest common layer is Layer 2 (Country). The transaction is routed directly to the Italian Layer 2 chain as a standalone settlement. The net totals of both metropolitan regions are adjusted — Rome's Layer 3 sub-tree is debited, Milan's Layer 3 sub-tree is credited — and the balance change propagates downward through each affected sub-hierarchy until it reaches the individual account level. No data about this transaction travels to Layer 1 or Layer 0. Italy's continental and global settlement totals are unaffected.

If instead a user in Europe sends a payment to a user in the United States, the two parties share no common layer below Layer 0. The transaction is routed directly to the global Layer 0 chain as a standalone settlement. The relevant continental totals are adjusted accordingly, and the balance change propagates downward through the European and American sub-hierarchies respectively until it reaches the individual accounts.

In both cases, the rebalancing after settlement ensures that the net totals reported upward by each sub-unit in the next settlement cycle correctly reflect the adjusted state. The routing rule is always the same: find the lowest layer in the hierarchy that contains both parties, and settle there.

The global layer consolidates the continental totals into a final worldwide settlement record. At each step, the volume of data processed is proportional to the number of sub-units at the layer below, which is a small, geographically determined constant — not a function of network transaction volume.

3.6.3 Fraud Detection via Settlement Discrepancy

The net settlement mechanism provides a natural fraud detection channel. Because each net total is cryptographically signed by the consensus of the layer that produced it, any discrepancy between the signed outgoing total and the corresponding incoming total at the layer above surfaces immediately at the first consolidation attempt.

If a city district signed off on more outgoing value than was covered by the available collateral pool in its micro-cells, the mismatch becomes visible when the metropolitan layer above attempts to reconcile its incoming totals against its known state. Individual transactions do not need to be replayed. The gap in the aggregate identifies the problem layer, and investigation proceeds downward from there — from metropolitan to city district, and if necessary from city district to individual micro-cell — until the discrepant transaction set is located.

This fraud detection model is computationally efficient because it begins at the top of the affected sub-hierarchy and drills down only as far as necessary to find the discrepancy. In practice, the collateral mechanism described in Section 4.2 prevents the vast majority of potential discrepancies before they occur.

3.7 Network Node Architecture: Two Tiers

The ProxCell network operates across two distinct tiers of node infrastructure that serve different roles, run on different hardware, and operate under different availability expectations. Understanding this distinction is important because the network is not, and cannot be, sustained solely by mobile phones.

3.7.1 The Consumer Tier: Mobile Nodes at Layer 5 and Layer 4

Mobile phones constitute the consumer tier of the network. They participate in geo-cell consensus at the micro-cell and city district layers, validate each other's transactions through the gossip-based propagation described in Section 4.1, and contribute to local collateral pools. Their participation is voluntary and non-continuous: a phone participates while its application is running and withdraws gracefully when it is not. The network is designed to tolerate this intermittent availability because the density of active consumer nodes in any populated area at any given time is sufficient to sustain local consensus. No individual mobile node is relied upon for continuity.

Consumer nodes are not expected to be archival. They hold recent local state — the current snapshot, recent transaction hashes for deduplication, and short-horizon GAA cache — and nothing more. Storage requirements on a mobile device are minimal by design.

3.7.2 The Infrastructure Tier: Dedicated Nodes at Layer 3 and Below

The settlement layers of the hierarchy — from the metropolitan layer downward to the global layer — require a different class of node: always-on, well-connected, storage-capable dedicated infrastructure. These nodes are responsible for receiving net settlement totals from the layers above them, maintaining the archival record of settlement history for their geographic scope, participating in the PoP-based consensus of their layer, and serving state snapshots to mobile nodes that need to bootstrap or resync.

The infrastructure tier is fully open and permissionless. Anyone who wishes to operate a dedicated node and contribute to the network may do so, subject to the Proof of Participation mechanics that govern admission and scoring at each layer. The range of participants who may choose to run infrastructure nodes is broad and by design: a financial institution seeking to integrate the network's settlement layer into its own systems, a regulatory body seeking an auditable record of settlement flows in its jurisdiction, a private citizen motivated by ideology or commercial interest in network fees, an exchange seeking low-latency access to settlement data, or any other party that sees value in participating. The protocol does not discriminate between them. Admission is governed by the same permissionless PoP rules at every layer.

This openness is also the source of the settlement layers' resilience. No single operator controls any layer. The federated structure of the infrastructure tier — many independent nodes across many operators, coordinated only by the protocol — means that the continuity of settlement does not depend on the goodwill or continued operation of any particular participant.

3.7.3 Archival and Distributed Storage

A specific class of infrastructure node is the archival node, which maintains a full historical record of settlement activity for its geographic scope rather than pruning older data. Archival nodes serve block explorers, compliance queries, dispute resolution, and any application that needs access to historical settlement records beyond the short retention window of standard nodes. Because archival storage requirements grow over time, archival nodes are typically operated by well-resourced participants: institutions, exchanges, or dedicated service providers who monetize access to the historical record.

Distributed storage across the infrastructure tier also provides the mechanism by which state snapshots — the compressed representations of current account balances and registry state — are made available to mobile nodes joining or rejoining the network. A mobile node does not download its snapshot from a central server. It queries the infrastructure tier of its local geographic layer, receives the snapshot from whichever nodes hold it, and verifies it against the spine chain hash before importing it. The distribution of snapshot hosting across many infrastructure nodes ensures availability without single points of failure.

3.7.4 The Settlement Layers as the Network's Foundation

The relationship between the two tiers can be understood as follows. The consumer tier is the network's surface: the part that users interact with, the part that processes transactions at human timescales, the part that is geographically distributed down to the individual level. The infrastructure tier is the network's foundation: the part that provides continuity, stores the record, settles the accounts, and connects the local consumer layer to the global financial system.

Neither tier is sufficient alone. A network of only mobile phones would have no archival record, no reliable settlement layer, and no path to institutional integration. A network of only dedicated infrastructure nodes would have no consumer reach, no geographic distribution at the transaction level, and no resistance to the centralization pressures that dedicated infrastructure naturally creates. The two-tier architecture is the resolution of this tension.

3.8 Geographic Account Addressing

Each account in the ProxCell network has two distinct identifiers that serve different purposes. The first is its cryptographic identity: a public key that is permanent, globally unique, and never changes regardless of where the account holder is in the world. The second is its Geographic Account Address (GAA): a mutable, hierarchical address that encodes the account's current position within the layer hierarchy, structured in a format analogous to IPv6.

A GAA reads from left to right in decreasing geographic scope. Each segment corresponds to one layer of the hierarchy: continent, country, region, metropolitan area, city district, and micro-cell, followed by a short unique suffix that distinguishes the account within its current micro-cell. A user currently in Rome might have a GAA such as:

EU.IT.LAZ.ROM.04.A3F7.9C2E

The same user traveling to Jakarta would acquire a new GAA reflecting their new location once they establish presence in the local geo-cell network:

AS.ID.JAV.JKT.07.B12A.9C2E

The trailing suffix remains constant and tied to the account's cryptographic identity. Everything to the left of it is location-derived and changes as the user moves.

3.8.1 The GAA is Not On-Chain

The GAA is deliberately ephemeral and lives entirely outside the blockchain. It does not need to be stored on any chain, validated by consensus, or globally synchronized. It is routing metadata, not financial state. Its accuracy matters for the duration of a transaction initiation and no longer.

A GAA can be distributed and discovered through any convenient mechanism: direct device-to-device exchange over NFC or Bluetooth at the moment of payment, propagation through the local P2P geo-cell network, a lightweight micro-DNS service, a RAM-resident lookup cache, or simply shared out-of-band by the recipient through any channel they choose — a message, a QR code, a link. The protocol does not mandate a discovery mechanism. It only requires that the sender have a current GAA for the recipient before routing begins.

Because the address is ephemeral, caching it for a day or two on the sender's device is entirely sufficient for most use cases. A merchant's GAA changes only when they move, which is infrequent. A friend's GAA changes only when they travel to a different city district or beyond. For local payments, the GAA is typically exchanged implicitly during the NFC or Bluetooth handshake that initiates the transaction itself, with no separate discovery step required at all.

3.8.2 Routing from the GAA

Once the sender has both their own GAA and the recipient's GAA, the routing decision is trivial. The two addresses are compared segment by segment from left to right. The first segment where they diverge identifies the lowest common layer — and therefore the layer at which the transaction must settle. A sender in Rome paying a recipient also in Rome will share all segments down to the micro-cell level, and the transaction settles at Layer 5. A sender in Rome paying a recipient in Milan shares segments down to the country level (EU.IT), so the transaction settles at Layer 2. A sender in Rome paying a recipient in Jakarta shares only the continent segment at best, or diverges at the first segment for a Layer 0 settlement.

This comparison requires no network lookup, no global state, and no consensus. It is a local computation performed in milliseconds on the sender's device.

3.8.3 GAA as an Anti-Spam Primitive

An incidental but valuable property of the GAA model is that it introduces a natural friction against unsolicited transactions. To send value to an account, the sender must first obtain a current GAA for that account. This is trivially easy between parties who choose to transact — they exchange GAAs directly — but it is non-trivially difficult for a spammer attempting to flood random accounts with dust transactions or unwanted value transfers. Unlike a blockchain address, which is permanently public and globally enumerable, a GAA is ephemeral and obtained through contact, not discovery. An account that does not share its GAA cannot easily be targeted.

3.8.4 GAA Staleness and the Forwarding Chain

When an account holder moves and their GAA changes, the outgoing GAA is not simply discarded. Before a node abandons its old micro-cell registration, it publishes a forwarding record: a signed pointer linking the old GAA to the new one. This record is not written to any chain. It lives in a lightweight, distributed cache spread across the sub-layers that served the old GAA — conceptually similar to a mempool in structure, but ephemeral by design. Forwarding records expire after a short window, typically a day or two, and are stored only as long as they are likely to be useful.

This creates a short traversable history. If a sender holds a cached GAA that has since become stale, their routing attempt reaches the old layer, finds the forwarding record, and follows the pointer to the new GAA. The process repeats if the account has moved more than once within the expiry window, walking the chain until it arrives at a current registration or the chain ends.

The mechanism works naturally for continuous movement. A user driving across a city will have a forwarding chain where each hop is geographically close to the previous one. The routing adjustment is small, the pointer is found quickly, and the transaction completes without any action from the sender. The chain reflects the physical reality of gradual movement.

It does not attempt to handle discontinuous movement, nor should it. A user who closes the application, boards a flight, and reopens it in a different country has made no intermediate registrations. There is no forwarding chain to follow because there was no continuous presence to generate one. In this case the stale GAA simply returns no forwarding record, the sender receives a routing failure, and the correct response is to request a fresh GAA from the recipient directly. This is not an edge case to be engineered around — it is the expected behavior, and the expectation of the sender should match it. The forwarding chain is a convenience for gradual drift, not a substitute for direct address exchange after a discontinuous jump.

3.9 Dynamic Layer Activation and Volume-Driven Depth

The geographic hierarchy described in this paper is not a fixed structure that springs into full existence at network launch. It is a living architecture whose depth at any given location is determined by the number of participants present there. A layer becomes active as an independent consensus unit only when the participant population in its geographic scope reaches the minimum threshold required to sustain meaningful consensus. Below that threshold, participants in that scope settle through the layer above. The hierarchy, in other words, starts shallow and earns its depth.

This principle can be made concrete with a simple example. Suppose at early network adoption there are one hundred users in Italy, one hundred in France, fifty in Indonesia, and two hundred in the United States. No single Italian city has enough users to justify a dedicated city-district chain. Rome might have eight users, Milan twelve, Naples four. There is no consensus to be had at city-district granularity with those numbers. All Italian users therefore settle at the country layer — a single Italian national chain handles their transactions. France is in the same position. Indonesia, with only fifty users spread across a vast archipelago, may not even justify a national chain yet and settles at the continental layer. The United States, with two hundred users, might have enough density in New York and Los Angeles to warrant the first metropolitan sub-layers to activate, while the rest of the country still settles at the national level.

As adoption grows, the depth grows with it. When the number of users active in Rome crosses the threshold for a city-district layer, that layer activates. Participants in Rome begin settling locally rather than routing to the Italian national chain. The national chain's load decreases proportionally. When a specific neighbourhood in Rome accumulates enough users for a micro-cell to sustain its own consensus committee, the first Layer 5 cells emerge there. This is not a planned rollout — it is an emergent consequence of the threshold mechanics, happening organically wherever the network achieves sufficient density.

The threshold-driven model has significant practical advantages beyond elegance. At genesis, the network requires only its uppermost settlement layers to be operational. A global layer and a small number of continental layers are sufficient to serve any initial user population regardless of how that population is geographically distributed. There is no need to pre-provision city-district chains for cities that have no users yet, no need to maintain empty metropolitan chains in countries where adoption has not yet arrived. Infrastructure cost and complexity at launch are minimal. The architecture scales to planetary coverage precisely because it does not attempt to instantiate planetary coverage on day one.

The depth of the network is also reversible. If a region's active user population declines below a threshold — as might happen if a competing platform absorbs users in a specific market, or if a temporary event creates a transient spike that then subsides — the sub-layer can be deactivated. Settlement responsibility migrates upward to the layer above without any loss of data or financial state. Accounts that were resident in the deactivated layer are absorbed into the parent layer's settlement scope until the population recovers. This reversibility makes the architecture robust against adoption that is uneven, non-linear, or subject to reversal, which accurately describes how any real-world network grows.

The precise threshold values — the minimum number of active accounts required to activate a Layer 5 micro-cell, a Layer 4 city district, and each layer above — are protocol parameters that require careful calibration. Set too low, the network fragments into many nearly-empty sub-layers that cannot achieve reliable consensus. Set too high, users in densely populated areas are denied the latency and performance benefits of local settlement longer than necessary. The hysteresis band around each threshold — the gap between the activation level and the deactivation level — must be wide enough to prevent a sub-layer from flickering on and off as a population oscillates near the boundary. These are empirical questions that will be addressed through testnet observation and formal analysis in subsequent specifications.

4. Consensus Mechanism

4.1 Local Fast-Path Consensus

When a ProxCell transaction is initiated, the payment application identifies the set of geo-cell nodes that have visibility of both the sender's and the receiver's accounts. This local consensus committee is typically composed of all nodes currently active within the geographic intersection of the relevant cells. The transaction is broadcast to this committee, validated against local state, and considered locally confirmed once a threshold of committee signatures is collected.

The local confirmation is not global finality. It is a strong probabilistic guarantee, backed by the economic collateral mechanism, that the transaction is legitimate and will be globally finalized unless fraud is subsequently detected. For the purposes of practical commerce — buying a coffee, paying a market vendor — this guarantee is sufficient.

4.2 Collateral-Gated Optimistic Execution

A transaction is eligible for the fast-path only if the sender's account holds a sufficient guarantee deposit beyond the transaction value. The guarantee deposit is a reserve that remains in the sender's account after the transaction is executed, providing an economic backstop in the event that fraud is detected before global finality. The ratio between transaction value and required remaining balance is a protocol parameter. An account that wishes to spend its entire balance at high speed is unable to do so because no guarantee deposit would remain. Such a transaction must wait for full settlement.

This mechanism aligns incentives: users who maintain healthy balances enjoy fast transactions. Users attempting to spend beyond their effective collateral capacity are automatically throttled to the slower settlement path.

4.3 Deferred Global Settlement

Locally confirmed transactions are batched within their geo-cell, aggregated into city district net totals after micro-cell deduplication, and then propagated upward as pure net settlement figures through the geographic hierarchy. Global finality is achieved when the transaction has been incorporated into the Layer 0 global state. At this point the guarantee deposit is released, the settlement is immutable, and no fraud dispute can reverse it.

4.4 Cross-Layer and Remote Transactions

It is important to distinguish two fundamentally different types of upward movement in the geographic hierarchy, because they operate by entirely different mechanisms.

The first is hierarchical net settlement, described in Section 3.6: local transactions within a geographic scope are aggregated into a single signed net total and passed upward automatically as part of the settlement cycle. These are not individual transactions traveling upward — they are accounting summaries. The individual transaction details remain local to the layer where they occurred.

The second is an individual cross-layer transaction: a single payment between two parties whose geographic scopes share no common layer below the one that contains them both. When an Indonesian user sends money to an American user, there is no common layer below Layer 0 that contains both parties. This transaction is submitted directly to Layer 0 as a single, individual settlement. It does not wait for a batch cycle. It does not travel through Layer 1, Layer 2, or any intermediate layer. It is routed directly to the lowest layer in the hierarchy that has jurisdiction over both parties.

Once a cross-layer transaction is settled at the appropriate layer, the resulting balance change must propagate downward to update the individual account balances in the respective sub-trees. The sender's balance is debited within their European sub-hierarchy. The receiver's balance is credited within their American sub-hierarchy. This downward propagation is handled by each layer in the path informing the layer below it of the relevant balance adjustment.

The fast-path local consensus described in Section 4.1 is not available for cross-layer transactions, since there is no shared local node committee that has visibility of both parties. Settlement occurs at the speed of the relevant layer — which is slower than local but appropriate for the use case. A payment from Europe to the United States that takes several minutes is not a degraded user experience in the same way that a slow coffee shop payment would be.

5. Location Attestation

5.1 Physical Contact as the Primary Attestation Mechanism

The ProxCell Protocol deliberately avoids relying on GPS coordinates as the primary location signal. GPS data is trivially spoofable at the software level. Instead, the protocol relies on physical device-to-device contact: NFC, which requires devices to be within a few centimeters, and Bluetooth Low Energy handshakes, which require devices to be within a few meters. The challenge-response exchange over these channels is signed by both devices and includes a timestamp and session nonce, making the attestation non-replayable and specific to the exact transaction.

Spoofing this mechanism requires physical hardware in the target location, not merely software modification. The counterparty's device must participate, which requires their cooperation. In standard commerce, the merchant has no incentive to assist a customer in committing fraud, even more if at their damage.

5.2 Multi-Signal Location Corroboration

Location attestation can be corroborated by passive environmental signals: nearby ProxCell nodes, cellular tower characteristics, and Wi-Fi access point presence. No individual signal is treated as authoritative. The composite signal provides a statistical fingerprint difficult to replicate outside the claimed location.

5.3 Merkle-Anchored Location History

Location attestations accumulate per account as a sequence of signed co-location events. Periodically this sequence is hashed into a Merkle tree and the root is posted to the network. The on-chain commitment is compact — only the Merkle root is posted, not individual events. This preserves privacy while maintaining auditability.

6. Security Model

6.1 Fraud Detection and Transaction Unwinding

Fraud is primarily the attempted double-spend: a single account initiating multiple transactions that collectively exceed its balance across different geo-cells before global settlement reconciles the state. The collateral mechanism prevents most attempts before they begin. In the rare case that a fraud slips through, it is detected at settlement consolidation as a discrepancy in the net totals, as described in Section 3.6.3. The guarantee deposit of the fraudulent account covers the loss. Nodes that co-signed fraudulent local confirmations are subject to protocol-defined consequences.

6.2 Sybil Attack Resistance

Each node must establish its location through actual payment interactions. Fake nodes without real payment counterparties cannot accumulate a credible location history and are excluded from consensus committees. A Sybil attack must dominate not just one cell but all overlapping cells in the target area. The geographic bucket isolation bounds the potential damage of any successful attack to its geographic scope.

6.3 Eclipse Attack Resistance

Because ProxCell nodes establish their peer set through physical proximity and payment interactions, an eclipse attack requires physical presence in the same area as the target. The overlapping cell structure means a node is connected to many independent cells, making complete isolation difficult.

6.4 Geographic Spoofing Resistance

The protocol resists software-level GPS spoofing by relying on physical contact rather than GPS coordinates. Hardware-level location spoofing requires physical proxy devices in the target location, raising the attack cost significantly. The Merkle-anchored location history makes it difficult to sustain a false location claim over time without creating detectable inconsistencies.

7. Multi-Currency Support

7.1 Currency Regionalization

The ProxCell Protocol is a multi-currency network. Each geographic layer naturally corresponds to a currency jurisdiction. The alignment between geographic layers and currency domains is a natural fit, and the geographic fund isolation described in Section 3.4 extends naturally to currency isolation: funds denominated in a given currency are predominantly held within the geographic layers where that currency is used.

7.2 Cross-Currency Settlement

Cross-currency transactions are handled at the appropriate layer in the hierarchy. The conversion is performed at the exchange rate agreed at the time of transaction, using the network's embedded conversion layer, which operates as a protocol-level component rather than a third-party service.

7.3 Currency Agnosticism at the Protocol Level

The protocol defines the consensus, settlement, and attestation mechanics without being tied to any specific currency. Whether the network adopts a single native token for internal accounting, uses fiat-denominated stable values, or operates with national currency representations is a deployment decision that does not affect the core protocol design.

8. Privacy Model

8.1 Pseudonymous Account Model

ProxCell accounts are identified by cryptographic key pairs. The account has no mandatory association with a real-world identity, email address, phone number, or device identifier. The network can verify that an account has sufficient balance to transact without knowing who controls that account.

8.2 Location Privacy

The Merkle commitments posted on-chain confirm that a valid co-location proof exists for a given transaction without disclosing exact coordinates. Users who choose to participate in geo-targeted commercial programs may optionally disclose more granular location data to those services, but this is a user-controlled opt-in feature, not a protocol requirement.

8.3 KYC and Regulatory Compliance

The protocol does not mandate identity verification at the account level but is designed to be compatible with KYC processes at the application or service layer. The separation of identity verification from the consensus layer allows the protocol to serve both regulated and unregulated use cases across different jurisdictions.

9. Node Participation and Network Incentives

The ProxCell network does not rely on financial mining rewards to incentivize node participation. Transactions carry minimal or zero fees. The primary incentive for running a node is access to the payment network itself. Secondary incentives include access to geo-targeted commercial opportunities: vouchers, discounts, and offers from nearby merchants made possible by the opt-in location data the network inherently produces.

The upper settlement layers — global, continental, national — do not need to run on mobile phones. They are natural candidates for dedicated server infrastructure operated by financial institutions, regulated entities, or independent validators, creating a participation model that spans from consumer smartphones at the micro-cell level to institutional infrastructure at the settlement layers.

10. Relationship to Existing Work

The ProxCell Protocol draws conceptual lineage from several existing distributed systems research areas, while combining them in a way that, to the author's knowledge, has not been previously proposed.

Table 2: Comparison of ProxCell Protocol with related distributed ledger architectures

10.1 IOTA and DAG-Based Architectures

IOTA introduced local tip selection in a directed acyclic graph. ProxCell shares the intuition that not every node needs to validate every transaction, but differs in making geography the primary organizing principle of local consensus and in introducing the hierarchical net settlement layer above the consumer consensus layer.

10.2 Lightning Network and Payment Channels

The Lightning Network achieves high-speed off-chain payments by locking funds in bilateral channels. ProxCell's optimistic execution with deferred global settlement is conceptually similar, but operates network-wide rather than requiring bilateral channel setup, and the net settlement aggregation provides a cleaner path to global finality without channel routing complexity.

10.3 Correspondent Banking

The hierarchical net settlement mechanism is structurally similar to how correspondent banking has operated for decades: banks do not transmit every retail transaction to each other but net their positions and settle the aggregate difference. ProxCell applies this model cryptographically and without trusted intermediaries, with net totals signed by decentralized consensus at each geographic layer rather than by a bank's own ledger.

10.4 Geographic Sharding Research

Geographic sharding has been explored in the Ethereum research community as an alternative to hash-based sharding. ProxCell is the first architecture, to the author's knowledge, to combine geographic sharding with physical proximity attestation, hierarchical net settlement, dual-chain state archiving, and collateral-gated optimistic execution as an integrated system.

11. Open Research Questions

The ProxCell Protocol as presented defines the conceptual architecture and core security model. The following questions remain open for further research and specification:

• Geo-cell consensus threshold: minimum node signatures for valid local confirmation, and how this varies with cell density and account risk profile.
• Guarantee deposit ratio: optimal ratio between transaction value and required remaining balance, static versus adaptive.
• Deduplication performance at scale: computational cost of Layer 5 to Layer 4 deduplication in high-density areas, and the conditions under which an intermediate aggregation sublayer is warranted.
• Proximity channel selection: optimal combination of NFC, Bluetooth, and corroborating signals for the co-location proof.
• Dual-chain bootstrap time: minimum snapshot size and download time for mobile node onboarding at each geographic layer.
• Settlement batch interval: optimal frequency for batching micro-cell transactions into city district net totals at different network densities.
• Privacy of location commitments: zero-knowledge proof constructions suitable for location anomaly detection without revealing precise geographic data.
• Cross-layer settlement protocol: formal specification of net total propagation, signature schemes, and conflict resolution at each layer transition.
• Currency conversion layer: exchange rate mechanism, atomic swap protocol, and liquidity management for cross-currency settlement.
• Regulatory interface: how the protocol's pseudonymous model interacts with jurisdictional requirements in practice.

12. Conclusion

The ProxCell Protocol presents a fundamentally different approach to the distributed payment network problem. Rather than attempting to speed up global consensus, it questions whether global consensus is required for most transactions at all. Rather than treating geography as irrelevant to network design, it makes geography the organizing principle of both consensus and fund management. Rather than propagating individual transaction records through the global hierarchy, it propagates only cryptographically signed net settlement totals, so that the global layer's workload is independent of network transaction volume.

The key contributions of the protocol are: physical proximity as a cryptographic security primitive; geo-cells as a dynamic, overlapping sub-network structure for local consensus; hierarchical net settlement with micro-cell deduplication at the Layer 5 to Layer 4 boundary and pure net aggregation above; geographic fund distribution isolating financial impact by scope; and multi-currency support aligned naturally with the geographic hierarchy.

Together these properties create a payment network that is fast where speed matters most — in local, in-person commerce — while remaining decentralized, privacy-preserving, and economically secure. The author invites rigorous scrutiny of the security model, economic assumptions, and implementation challenges as the protocol moves toward formal specification.

A Note from the Author

Roberto Capodieci

Distributed systems architect. Participant in the Bitcoin network since 2009. Designer of ZooBC. Author of the ProxCell Protocol.

The ideas in this paper did not emerge from a whiteboard exercise. They grew from years of building distributed systems that had to work in the real world, under real constraints, with real users who do not care about consensus algorithms but care very much about whether their payment went through.

I have been involved in distributed computing and cryptographic systems since the early days of the internet. I participated in the Bitcoin network from 2009, when it was still possible to understand the entire system by reading a single document. That experience of watching a genuinely novel architecture solve a genuinely difficult problem — trustless agreement between strangers — stayed with me for a long time. It also left me with a clear-eyed view of what Bitcoin did not solve, and what the wave of projects that followed it mostly failed to solve either: the problem of making decentralized consensus fast enough and cheap enough for the kind of commerce that happens between two people standing in the same room.

ZooBC, which I designed, was my attempt to address the decentralization problem at the consensus layer. The spine chain architecture, the Proof of Participation mechanism, the snapshot-based bootstrapping system — these were answers to specific failures I had observed in existing blockchain designs, built and tested over years rather than speculated about in a paper. The technical foundation of ZooBC is the direct ancestor of the implementation path described in this document.

The ProxCell Protocol is a different kind of contribution. It is not primarily a consensus innovation — it takes the dual-chain architecture of ZooBC and asks what happens when you organize it geographically rather than arbitrarily. The insight that physical proximity is itself a security primitive, that the payment act is a location proof, and that the global settlement problem dissolves when you stop requiring global consensus for local commerce — these came to me not from the literature but from thinking about how payments actually work in the physical world and asking why the distributed ledger community had spent a decade largely ignoring that reality.

I present this paper to establish clearly that these ideas originate here, with this authorship, at this time. The architecture described is novel in its specific combination, and it is mine. I offer it openly for scrutiny, collaboration, and implementation, with the confidence that comes from having built systems like it before.