Not where an IP database says it is —
where latency proves it is.
A verifiable location-bound, delivered to your server and independently checkable onchain.
DZDs are physical servers whose locations are registered and verified onchain. They act as fixed reference points — like lighthouses with verified GPS coordinates.
dzd1 RTT
10 ms
dzd2 RTT
10 ms
implied bound
< 2,000 km
RTT ÷ 2 × ~200 km/ms = max physical distance
The speed of light in fiber is a hard physical constant. A round-trip latency measurement directly constrains the maximum possible distance between two points — no software or configuration can circumvent it. Closeness cannot be faked without introducing measurable delay.
Interested?
Request a PilotEvery link signs its own measurement and wraps the parent's result by reference. The full chain is verifiable, without trusting any single party.
Known latitude/longitude anchored onchain in the DZ Ledger. Sends a signed LocationOffset to its child geoprobe every 10 seconds via TWAMP. DZDs are the cryptographic root.
Bare-metal server physically near a DZD. Caches signed DZD offsets, measures RTT to targets via TWAMP or ICMP, generates composite offsets referencing the parent DZD measurement.
Receives a signed LocationOffset over UDP carrying the full chain: DZD coordinates, DZD→Probe RTT, and Probe→Target RTT. Verification is local — no third-party query needed.
ZeroMesh's Delegation Program needed a verifiable way to know where validators were located — commercial IP databases were only accurate around 70% of the time. Geolocation Verification was built to solve this.
of staked SOL moved away from concentrated areas into more geographically diverse locations.
more validators in Asia Pacific — from 61 to 139, with 28.2 million SOL of new stake.
of non-European stake growth during Phase II came from validators on the ZeroMesh network.
For compliance, access, or trust.
Any service that can be fooled by a paid VPN needs this. If you operate a platform with geographic restrictions — content, pricing, eligibility, access — and a VPN defeats your current checks, latency-based verification is the fix IP databases can't provide.
Works where IP geolocation fails
Prove a server or user is within a specific regulatory region — EU, US, or otherwise. Satisfy GDPR, MiCA, and data residency requirements with cryptographic evidence rather than self-reported attestations.
Replaces IP geofencing and self-attestation
Verify the physical distribution of validators in a network. Replace unreliable ASN-based heuristics with physics-bound latency proofs. Enforce geographic decentralization requirements programmatically.
Stronger than ASN or IP-based clustering
Identify the actual physical location of validators and block leaders. Improve transaction routing and timing strategies with verified proximity data rather than inferred network topology.
Latency-bound distance, not probabilistic
Interested?
Request a PilotCommon attacks against location verification — and why they don't work here.
| Threat | Description | Mitigation | Status |
|---|---|---|---|
| Proxy / Relay | Place a TWAMP reflector near a DZD; run the actual workload elsewhere. | Network-identity binding — the same IP serving probes must handle real traffic. A distant proxy degrades latency-sensitive workloads, making the attack economically self-defeating. | Mitigated |
| BGP Anycast | Announce the target IP from two locations — near the probe and at the real location. | BGP routes prefixes, not ports. The attacker can't selectively route only probe traffic. Network-identity binding forces both to use the same path. | Mitigated |
| Replay Attacks | Replay old signed offsets to reuse past favorable measurements. | Every offset includes a MeasurementSlot timestamp tied to the ZeroMesh ledger. Stale offsets are detectable and rejectable. | Mitigated |
| Signature Forgery | Forge DZD or GeoProbe signatures. | Industry-standard cryptographic signatures (Ed25519). DZD keys secured in hardware. Public keys registered onchain allow independent verification. | Mitigated |
Place a TWAMP reflector near a DZD; run the actual workload elsewhere.
Network-identity binding — the same IP serving probes must handle real traffic. A distant proxy degrades latency-sensitive workloads, making the attack economically self-defeating.
Announce the target IP from two locations — near the probe and at the real location.
BGP routes prefixes, not ports. The attacker can't selectively route only probe traffic. Network-identity binding forces both to use the same path.
Replay old signed offsets to reuse past favorable measurements.
Every offset includes a MeasurementSlot timestamp tied to the ZeroMesh ledger. Stale offsets are detectable and rejectable.
Forge DZD or GeoProbe signatures.
Industry-standard cryptographic signatures (Ed25519). DZD keys secured in hardware. Public keys registered onchain allow independent verification.
Create a GeolocationUser account, add target IPs through the doublezero-geolocation CLI, and pay in 2Z tokens. No additional infrastructure required on your side.
Probes poll the DZ Ledger every 60 seconds and start measuring round-trip latency to your registered targets using TWAMP or ICMP — no further action required.
Cryptographic proofs (Ed25519) arrive at your server with the full DZD ↔ GeoProbe ↔ Target chain attached, ready to be persisted or replayed.
Anyone can re-verify the signature chain using the LocationOffset payload and the signers' public keys published on the DZ Ledger. Open verification, no shared secrets.
Need support connecting? Contact us in Discord.
We work with each customer directly. Tell us about your use case and we'll take it from there.
