DAGAMA 2.0: PROOF-OF- PRESENCE (POP) PROTOCOL

Introduction

This document provides an extended discussion of the challenges related to location determination and proof of physical presence, as well as an introductory overview of the architectural approach to building a Proof-of-Presence (PoP) protocol.

Why a Proof-of-Presence Layer Is Needed

Modern digital services increasingly require an understanding of user actions in physical space: visiting a location, attending an event, completing a route, or interacting with a physical object. However, the infrastructure that enables trust in such data remains deeply centralized and opaque.

Most spatial and behavioral data is collected and controlled by a small number of technology giants—Google, Apple, payment networks, mobile OS vendors, and large API platforms. These corporations hold monopolistic access to geolocation data, routes, device identifiers, and activity signals. Users, developers, and businesses only receive secondary access to this data through APIs, reports, and interfaces, without any ability to independently verify its authenticity or completeness.

This situation creates several fundamental problems:

  • Manipulability and opacity: Centralized providers can filter, distort, or aggregate data, eliminating the possibility of independent verification.

  • Lack of trust and anti-fraud weaknesses: Systems based on self-reported location (GPS, check-ins) are easy to spoof; GPS spoofing, QR forwarding, and proxy-device attacks are common.

  • Excessive data disclosure: When users share location data, they cannot control how much of it circulates further or who gains access.

  • Digital monopolization: Only the largest players can build spatial analytics based on primary physical-world signals.

This leads to a contradiction:

Demand for honest, privacy-preserving, and provable physical-world events is enormous, yet neither users nor independent projects can meaningfully work with spatial data without intermediaries.

Solution: A Decentralized Presence Layer

To resolve this contradiction, an open and decentralized Proof-of-Presence (PoP) protocol is required. It must guarantee that:

  • the event genuinely occurred in the physical world (e.g., a visit, participation, or route completion);

  • the proof is cryptographically verifiable without relying on a trusted intermediary;

  • no personal data is disclosed without consent;

  • any interested party—business, application, user, or smart contract—can participate on equal terms and access trustworthy events.

PoP does not aim to replace centralized systems. Instead, it provides an alternative trust layer for Web3 and hybrid applications. Just as DePIN networks digitize infrastructure, PoP enables decentralized digitization of facts of physical presence, unlocking new interaction models between people, devices, and smart contracts.

Problem Statement

Existing Positioning Systems and Their Limitations

Modern positioning systems combine multiple technologies depending on the environment (outdoor/indoor), infrastructure availability, and accuracy/latency requirements. Commercial solutions typically fuse GNSS, cellular positioning, Wi-Fi, proximity protocols (BLE, NFC, UWB), and inertial/visual sensors, followed by GIS-level interpretation (geofencing, POI matching, map-matching).

In practice, this answers the question “where is the device approximately?” but is insufficient when a provable physical event is required.

GNSS (GPS/Galileo/GLONASS/BeiDou) provides global coverage and acceptable accuracy outdoors, but degrades in urban canyons and indoors. More importantly, GNSS is not proof—it is a measurement vulnerable to interference and spoofing. It answers where the device believes it is, not whether an independent verifier can trust the event.

Cellular positioning (4G/5G) relies on timing, angle, or power measurements from base stations. While resilient where GNSS fails and increasingly standardized in 5G, results depend heavily on operator policies, station density, and radio geometry. It remains an estimate, not a cryptographically verifiable proof.

Wi-Fi positioning and Wi-Fi RTT (FTM) are widely used indoors and can reach meter-level accuracy, but suffer from NLOS, multipath, chipset variance, and infrastructure instability. Fingerprinting requires ongoing calibration and maintenance.

BLE beacons and proximity mechanisms offer cheap and scalable proximity detection, but RSSI is noisy, signals can be relayed or emulated, and proximity does not always equal physical presence.

UWB and RTLS provide high-precision ranging and are strong in controlled environments. However, they require infrastructure and are still vulnerable to advanced attacks unless combined with multi-layer verification.

Inertial and visual methods (IMU/PDR/VIO) provide high-frequency relative motion but accumulate drift and require external anchors.

The GIS layer converts coordinates into business facts (geofence entry, POI visit, route compliance). Many disputes arise here—not due to bad coordinates, but due to interpretation errors.

Overall, existing systems handle coordinates and context well, but suffer from four systemic limitations:

  1. Quality degradation in complex radio environments

  2. Lack of third-party verifiability

  3. Vulnerability to attacks and economically motivated fraud

  4. A conflict between data utility and privacy

For Web3 and DePIN, this is amplified by incentives: if physical events are rewarded, the motivation to fake them increases. Therefore, a dedicated infrastructure layer is required—one that confirms not coordinates, but facts of events under explicit verification policies.

Key Issues and Criticism

In the 2020s, research focus shifted from maximum accuracy to trustworthiness and system resilience. GNSS research increasingly emphasizes spoofing and jamming resistance. Indoor systems struggle with NLOS and environmental instability. UWB, while precise, is not automatically secure without layered defenses.

At the same time, centralization and privacy have become critical concerns. Location data is among the most sensitive categories of personal information, enabling inference of habits, relationships, and social graphs. This creates a structural conflict: businesses want behavioral analytics and verified actions, while users reject full trajectory disclosure.

In IoT and DePIN, economic incentives further complicate matters. Once rewards are attached to presence, attacks emerge: Sybil identities, witness collusion, radio-environment emulation, edge-device compromise, and off-chain trust assumptions.

Across literature and practice, the conclusion is consistent: many applications require provable events, not raw coordinates. This demands trust minimization, privacy-by-design (including ZK proofs), and economic anti-fraud mechanisms.

  • Rapid growth of the indoor/RTLS market

  • Advancing 5G positioning standardization (3GPP Releases 15–18)

  • Increased adoption and testing of Wi-Fi RTT/FTM

  • Expansion of UWB and secure ranging, alongside growing academic scrutiny

  • Rising GNSS jamming/spoofing incidents driving detection and mitigation investment

Threat Model

Key threats include:

  • GNSS spoofing and jamming

  • Replay and relay attacks

  • Infrastructure impersonation (fake beacons/APs)

  • Edge-device compromise (rooting, firmware tampering)

  • Sybil attacks and validator collusion

  • Data/model poisoning (if ML is used)

  • Insider threats (operators, API providers, administrators)


Requirements for Proof-of-Presence Systems

Functional Requirements

  • Event confirmation: “entity was in zone X during time T”, “completed route”, “interacted with object Y”

  • Third-party verifiability without raw sensor access

  • Support for multiple scenario types (point, route, participation, interaction)

Non-Functional Requirements

  • Integrity and confidence scoring

  • Environmental robustness (NLOS, multipath, interference)

  • Fraud resistance (spoofing, replay, Sybil, collusion)

  • Scalability and batching

  • Interoperability across signals, devices, and chains

  • Privacy-by-design and controlled disclosure

  • Auditability

  • Reasonable total cost of ownership


Target Properties of the PoP Layer

Trust Minimization and Independent Verification

Events are confirmed by independent validators and yield a cryptographically verifiable attestation usable by smart contracts.

Multi-Signal Robustness

Fusion of GNSS, Wi-Fi, BLE, UWB, IMU, and local anchors to handle real-world conditions.

Resistance to Economically Motivated Attacks

Stake- and reputation-based validator access, collusion detection, and policy-dependent assurance levels.

Privacy-by-Design

Only hashes/commitments are public; raw data is encrypted or omitted. ZK proofs enable statements like “was in geozone” without revealing coordinates.

Standardized Attestation Object

A PoP-Attestation includes:

  • event type and ID

  • time window

  • zone/object identifier

  • data commitment

  • validator signatures

  • confidence and policy metadata

Modularity (SDKs, Hardware, Contract Factories)

Mobile SDKs, hardware SDKs, APIs, and smart-contract factories enable rapid integration.

DGMA-Based Attestation Economy

DGMA acts as both settlement and incentive token, with mechanisms to keep mass usage affordable.


PoP Protocol Architecture

The protocol consists of:

  1. Hardware / Edge Layer — event generation at the physical boundary

  2. Validation Network — oracle and validator cross-verification

  3. Publication Layer — on-chain/off-chain anchoring

  4. Integration Layer — SDKs, APIs, and contract factories

5.1 Hardware Layer

Principles: data minimization, pseudonymization, multi-signal support, separation of fact from detail.

Sources include mobile devices, PoP hardware (beacons, terminals), hybrid QR/NFC/BLE triggers, and duration-based presence scenarios.

Each PoP event contains:

  • event type

  • target zone/object ID

  • time window

  • payload hash

  • cryptographic authenticity markers

  • pseudonymous participant ID

  • optional environment indicators


Validation Layer: Oracle and Validator Network

Roles include:

  • Witness Nodes (basic validation)

  • Geo-Verifiers (geographic/context checks)

  • Consistency Nodes (anti-fraud and pattern analysis)

  • ZK Validators (zero-knowledge proof verification)

A local consensus model confirms each event via a configurable quorum, producing a PoP-Attestation.

Last updated