A stadium vendor has a digital pass good for "one drink" at a concert. But the pass should only be valid inside the stadium. If the vendor walks out with the pass, it shouldn't work. Traditional tokens don't know geography. They're valid everywhere or nowhere.
DUAL's Zone Tokens embed location awareness directly into the token: a geofence polygon that defines where the token is valid. When a mobile device queries the token, it provides GPS coordinates. The token validates: "Are you inside the boundary? Yes → Token active. No → Token inactive."
This unlocks entire economies that were previously impossible: location-based access control, watershed-specific water rights, stadium-only merchant tokens, and carbon credits that can't be double-counted across overlapping project boundaries.
Three Geo-Positioned Token Systems
Case 1: Zone Tokens — Location-Based Access Control
A concert stadium issues 5,000 vendor passes for a single-day event. The pass has simple properties:
{
"token_id": "vendor_pass_stadium_042801",
"current_state": "ACTIVE",
"geofence": {
"type": "POLYGON",
"coordinates": [
[40.7128, -74.0060], // Stadium corners
[40.7145, -74.0040],
[40.7150, -74.0070],
[40.7120, -74.0075]
],
"buffer_meters": 0 // Strict boundary
},
"vendor_did": "vendor_001_did",
"valid_until": 1712730000 // End of event
}When a vendor scans the pass at a gate:
- Device sends GPS coordinates (40.7135, -74.0062)
- Token checks: is this point inside the polygon?
- Token checks: is timestamp before valid_until?
- If both true: "VALID". Gate opens.
- If false: "INVALID". Gate rejects.
The vendor walks out of the stadium. Coordinates now (40.7160, -74.0090) — outside polygon. Token state is still "ACTIVE" (unchanged), but the geofence check fails. The token is valid, but not active at this location.
This is more powerful than revocation. The token isn't burned. The vendor re-enters the stadium, shows their pass, and it works again. Location is the arbiter of validity.
Case 2: Carbon Integrity — Preventing Double-Counting Through Geo-Pinning
Carbon credits are vulnerable to a critical fraud: double-counting. A reforestation project in the Amazon might sell credits to both a European carbon exchange and a North American one. The same tree is counted twice.
Carbon Integrity tokens embed the precise geography of the project:
{
"token_id": "carbon_reforest_2024_amazonas_001",
"face_value": 1000, // 1000 tons CO2e
"current_credit_value": 980,
"project_location": {
"country": "Brazil",
"state": "Amazonas",
"coordinates": [-3.1234, -60.5678],
"project_boundary": {
"type": "POLYGON",
"coordinates": [
[-3.1200, -60.5600],
[-3.1250, -60.5600],
[-3.1250, -60.5750],
[-3.1200, -60.5750]
]
}
},
"last_satellite_verification": 1712620800,
"verified_forest_coverage_percent": 98
}Each time a carbon credit is sold or transferred, the token's geofence prevents sellers outside the project boundary from minting duplicate credits. Here's why:
- Project's geofence is [3.1200, -60.5600] to [3.1250, -60.5750]
- Only actors whose GPS location falls within this boundary can mint or transfer credits
- An actor in Europe trying to mint a duplicate credit is GPS-checked against the boundary
- Coordinates don't match → Transaction denied
This is especially powerful combined with DUAL's Event Bus. Satellite imagery fires an event: "Forest coverage 98% verified." The token updates. But the geofence doesn't change. The integrity of the credit is location-proof.
Case 3: Water Rights Allocation Based on Watershed
AquaAlloc tokens allocate water rights within specific watersheds. A farmer in the Colorado Basin receives a water rights token good for 50 acre-feet/year. But the token is only usable within the Colorado Basin boundaries.
{
"token_id": "water_rights_colo_basin_farm_042",
"allocation_acre_feet": 50,
"used_acre_feet": 12,
"remaining": 38,
"valid_watershed": {
"name": "Colorado River Basin",
"geofence": {
"type": "POLYGON",
"coordinates": [
[41.0000, -109.0000],
[31.0000, -109.0000],
[31.0000, -114.7000],
[41.0000, -114.7000]
]
}
},
"farm_location": {
"lat": 39.5501,
"lng": -107.8779
}
}When the farmer submits a water draw request (pull 10 acre-feet from their well), the token checks:
- Is the farm location within the Colorado Basin geofence? Yes
- Do they have 10 acre-feet remaining? Yes (they have 38)
- Draw water, decrement used_acre_feet by 10
If the farmer tries to move their operation to California and transfer the token, the token's geofence prevents it. The token is bound to the Colorado Basin. Water rights can't migrate between watersheds—a critical regulation for water scarcity regions.
Why Native Geo-Positioning Beats Oracles
The naive approach: use a price oracle (e.g., Chainlink GPS oracle) to fetch location data on-demand. But this creates multiple problems:
| Concern | Oracle-Based | DUAL Native |
|---|---|---|
| Latency | 3-5 seconds (oracle call + settlement) | Instant (local geofence check) |
| Cost | $0.50-2.00 per location check | < $0.001 (embedded logic) |
| Reliability | Depends on oracle uptime | Always available |
| Spoofing Resistance | Oracle can be attacked or compromised | Cryptographically signed GPS data |
DUAL doesn't eliminate the need for GPS oracles entirely. Satellite imagery for carbon verification still uses oracles. But for the day-to-day token validity checks, location is native and instant.
Practical Example: Stadium Concessions Vendor Token
A concert has 200 food vendors. Each vendor gets a "vending license" token valid only inside the stadium and only for the duration of the event:
{
"token_id": "vendor_lic_stadium_concert_042801",
"current_state": "ACTIVE",
"vendor_name": "ABC Catering",
"geofence": {
"center_lat": 40.7128,
"center_lng": -74.0060,
"radius_meters": 300 // Stadium size
},
"valid_from": 1712680000, // Event start
"valid_until": 1712730000 // Event end
}A customer buying food asks: "Is this vendor licensed?" The customer's phone queries the vendor token:
- Customer's phone provides GPS coordinates: (40.7130, -74.0058)
- Token geofence checks: distance from center = 70 meters. Within 300m radius? Yes.
- Timestamp check: Is current time between valid_from and valid_until? Yes.
- Token returns: "VALID. This vendor is licensed."
If the vendor walks outside the stadium, coordinates become (40.7160, -74.0090). Distance from center = 900 meters. Within 300m? No. Token returns "INVALID outside authorized zone."
The license isn't revoked. It's geo-locked. The vendor re-enters, and it works again.
Multi-Zone Tokens: Complex Boundary Logic
Some tokens operate across multiple geofences. A Spectrum Allocation token might be valid in multiple geographic regions simultaneously:
{
"token_id": "spectrum_license_region_alpha",
"valid_zones": [
{
"name": "Northeast_Metro",
"geofence": { // Polygon for NYC metro area }
},
{
"name": "Mid_Atlantic",
"geofence": { // Polygon for Philadelphia metro area }
}
],
"forbidden_zones": [
{
"name": "Military_Base_XYZ",
"geofence": { // Polygon around military installation }
}
]
}When checking validity, the token uses boolean logic:
Valid if: (in Northeast_Metro OR in Mid_Atlantic) AND NOT in Military_Base_XYZ
This enables sophisticated regulatory boundaries: a wireless spectrum license valid in two regions but not in a military zone.
Performance: O(1) Geofence Checks
A concern: with thousands of tokens being queried simultaneously, won't geofence checks become slow?
No. Point-in-polygon checks are O(1) constant time for convex polygons (most real-world boundaries). Even complex boundaries with 100+ vertices complete in <1ms.
A stadium with 50,000 concurrency phones checking vendor tokens simultaneously: 50,000 parallel geofence checks, each <1ms. Total time: ~1ms system-wide. Compare to oracle-based: 50,000 × 3 seconds = 150,000 seconds of oracle latency.
What's Next
So far we've explored tokens for physical assets and real-world compliance. But DUAL's architecture is equally powerful for digital agents. In Part 5, we'll examine how tokens govern AI agents: embedded spending limits, counterparty whitelists, and real-time compliance checks that allow autonomous agents to transact billions of dollars with zero human intervention.