Proving Location with Physics: Geolocation Verification on DoubleZero

Location on the internet is a best-effort guess. IP geolocation databases have somewhere between 50–70% city-level accuracy under good conditions, and worse in the cloud and colocation environments where most production infrastructure lives. GPS is precise but requires hardware access to datacenter rooftops that simply isn't practical at scale. Self-attestation, or where an operator independently reports where they are, is trivially, fakeable and offers no assurance for compliance or governance.

DoubleZero Geolocation Verification is a different kind of system. Instead of asking where a server says it is, it measures how far the server is from infrastructure with a known, onchain-verified location. The measurement is bound by physics, signed with Ed25519 keys, and delivered as a verifiable data structure that any third party can check independently.

DoubleZero's geolocation verification service defined in RFC 16 is signed, physics-bounded proof of where a server actually is. This post explains how the system works, why the design choices were made the way they were, and what threat model it actually defends against.RFC 16 defines DoubleZero's geolocation verification service: cryptographically signed, physics-bounded proof of physical location for any IP endpoint, independently verifiable by any third party using the DZ Ledger's public key registry.

A customer registers an IP address, geoprobe servers measure round-trip latency from DoubleZero Devices (DZDs) at precisely known coordinates, and the full measurement chain is signed with Ed25519 at every link and anchored onchain. The result is a `LocationOffset` message stating "X milliseconds from latitude Y, longitude Z."

Physics converts that directly to a distance bound. At the speed of light through fiber (~200km per millisecond), a measured round-trip time sets a hard ceiling on where a target can be. Location becomes a provable signal rather than a best-effort guess.

This matters because no existing production system combines high-quality latency measurement with a cryptographic proof chain. IP geolocation databases typically deliver 50–70% city-level accuracy, degrade further for cloud and co-location addresses, and carry no audit trail. Active probing services are functionally closer but use proprietary methodology, produce no signed output, and require trusting the operator's data. GPS requires rooftop antenna access in every datacenter. Self-attestation, where operators simply declare their location, provides no basis for compliance or governance. The gap is a verification problem: no existing approach lets a third party independently confirm the measurement is real and the data hasn't been altered.

The Measurement Chain

The architecture uses three tiers: DZD, geoprobe, and target. Each DZD has latitude and longitude registered on the DZ Ledger. Every 10 seconds, the DZD sends TWAMP probes to its assigned child geoprobes and generates a signed `LocationOffset` carrying its coordinates and the measured round-trip time. The geoprobe, a bare metal server co-located with its parent DZD, caches those DZD-signed offsets. When a target is registered onchain, the geoprobe measures RTT to that endpoint via TWAMP or ICMP, wraps the DZD's offset as a reference, signs the composite structure, and delivers the result over UDP.

Each `LocationOffset` is a 174-byte fixed header plus a variable reference chain, sent over UDP on port 8923. The fixed fields carry the Ed25519 signature, the signer's authority public key, the device public key (DZD or geoprobe), the DoubleZero measurement slot, WGS84 latitude and longitude, `MeasuredRttNs` (the direct RTT to the immediate target), `RttNs` (the composite RTT from the reference lat/lng through all intermediate hops), the target IPv4 address, and a reference count. For geoprobe-generated offsets, the References field embeds the parent DZD's `LocationOffset`, allowing any recipient to walk the full chain and verify every signature back to a root of trust on the DZ Ledger.

Why It Can't Be Faked

The physics is the constraint. Light travels through fiber at approximately 200km per millisecond. A measurement reporting 5ms RTT from Frankfurt places the target within a 1,000km radius of Frankfurt. That is not an approximation. It is a physical upper bound. No amount of software manipulation compresses 10,000km of fiber between Singapore and Amsterdam into 5ms of round-trip time.

Chain verification closes the software side. The DZD signs its offset with its Ed25519 key. The geoprobe signs the composite offset with its own key. The target receives both, verifies each signature against the public keys registered onchain, and can confirm the measurement came from a specific DZD at a known location through a specific geoprobe at a measured proximity.

Neither the DoubleZero Foundation nor any single contributor needs to be trusted. Any party can re-verify the full chain independently using the `LocationOffset` payload and the signers' public keys. The result is composable: once received and verified, it can be forwarded to external systems or stored for audit without querying DoubleZero again.

Three Probing Modes

The service supports three modes to fit different target environments.

Outbound mode has the geoprobe initiate TWAMP probes to the target. This requires the target to run software listening on UDP ports 8923 and 8925.

Outbound ICMP mode requires only that the target responds to ICMP pings. No software installation is needed on the target. An alternate offset receiver handles `LocationOffset` delivery.

Inbound mode inverts the initiation, but the geoprobe still does the measuring. This mode is designed for two applications: trusted execution environments (TEEs) that can't open ports, and applications that want to verify the location of a signing key. The target signs a custom TWAMP-style message, and sends it to the geoprobe. The geoprobe replies with a nonce. The target puts the nonce in a second TWAMP-style message, signs it, and sends it back to the geoprobe. The probe measures the time between receiving the two messages. The geoprobe's second reply includes a signed measurement and reference chain. In the case of a TEE, the target can skip including the nonce and pre-sign both TWAMP probes, since the user knows that their code can't send the second probe before receiving the first reply. The geoprobe handles this difference gracefully, and notes whether the nonce was included in its measurement.

What It's Built For

The geolocation verification service is designed for organizations that need to verify the location of known infrastructure, not estimate the location of unknown users. That distinction matters for understanding what the service is and what it isn't.

The primary use cases fall into a few clear categories:

Compliance and jurisdiction verification is the most direct application. A system can use `LocationOffset` measurements to establish that a server is plausibly within a specific region. This provides a secondary verification layer on top of IP or GPS data, useful in systems where location is a relevant input for jurisdiction-related decisions.

Token distribution and airdrop enforcement is a strong fit. Geographic eligibility rules are common in token launches, and existing approaches using IP databases or VPN-detection heuristics are straightforward to circumvent. A physics-bounded latency proof using inbound probing to verify a wallet is located in an allowed jurisdiction is not. It is resistant to VPNs, proxies, and spoofed GPS coordinates because none of those techniques reduce the speed of light.

Validator location verification addresses a real gap in how blockchain networks measure decentralization. ASN-based heuristics and self-reported node locations are easy to manipulate. `LocationOffset` measurements anchored to onchain DZD coordinates provide a verifiable basis for assessing whether a validator is actually distributed where the operator claims. Trading firms and validator ecosystems evaluating leader location for routing and transaction delivery optimization are a natural secondary audience here.

This is not designed for high-volume lookups across unknown or transient IPs, real-time geolocation of website visitors, or fraud detection at internet scale. It verifies known infrastructure at meaningful depth. That is a narrower scope than general IP geolocation, and the right scope for what the system can actually prove.

Getting Started

Registration is self-service. A customer creates a `GeolocationUser` account on the DZ Ledger using the `doublezero` CLI, then adds endpoints with `doublezerogeolocation`. Geoprobes poll the ledger every 30 seconds to discover paying targets and begin measuring automatically. `LocationOffset` messages start arriving over UDP. The customer verifies the Ed25519 chain from DZD to geoprobe to target, confirms signor pubkeys against the DZ Ledger, and ingests the location data into their systems.

For contributors already operating at active DoubleZero exchanges, a co-located geoprobe is a new revenue line that runs on the same TWAMP protocol the telemetry agents already use on every DZD. The new component is a small server running the geoprobe service in Go.

Where Things Stand

The full technical specification is published as RFC 16. The service is up and running in mainnet-beta with a limited set of initial probes covering roughly 25 metro areas. A pilots stage will add additional geoprobe operators and additional probes per metro, to better establish coverage.

For contributors who can co-locate a geoprobe near an active DZD and are interested in running an early pilot, the engineering team at Malbec Labs is looking for operators to help shape allowlist criteria, SLAs, and hardware baselines. Expressions of interest are welcome.

The full engineering design is in RFC 16 — Geolocation Verification.

Live network topology and DZD locations: data.malbeclabs.com.

Product overview for operators interested in co-locating a geoprobe for early pilots: doublezero.xyz/geolocation-verification.