Mapping 89 Native Field Names to 38 Canonical Concepts: The DePIN Schema Problem
Decentralized Physical Infrastructure Networks (DePIN) present a unique ontological challenge. Unlike traditional cloud infrastructure where telemetry follows standardized schemas (e.g., OpenTelemetry metrics), DePIN protocols operate in semantic silos. Each protocol defines its own ontology. At Kairos Signal we read first-party telemetry from 296 networks across 69 distinct data sources — and no two of them name a metric the same way.
Take "active nodes." Akash calls it active_providers; io.net exposes active_devices; Render reports node_operators; Helium tracks online_hotspots. On the surface these all describe the same thing. But they do not — the definitions differ in whether they count the unit, whether the unit is online, and what the unit is. If you naively compare active_providers against active_devices you will draw conclusions the data does not support.
The 89-to-38 Collapse
Across the networks we track, we observe 89 distinct native field names that reduce to 38 canonical concepts. The reduction is not a rename — it is a transformation that carries unit declarations, freshness semantics, and a documented definition for each target concept.
A canonical concept is defined by three things:
gpu_active means "GPU instances reporting a heartbeat within the freshness window," not "GPUs ever registered."verify_url on the originating network, so a consumer can confirm the raw reading.The mapping from native name to canonical concept is not one-to-one. Some native names split into two canonical concepts (e.g., registered vs active). Some canonical concepts aggregate multiple native names (e.g., storage_capacity unions several provider-reported fields). Some native names are rejected outright because they are undefined or unitless.
The "Same-Question Guarantee"
The core promise of canonicalization is that the same question always returns the same concept. When you query storage_active for Filecoin and then for Storj, you are asking the identical question, and the answer is comparable. This is enforced not by documentation but by automated self-tests.
Every hour we run a suite of same-question probes: for each canonical concept, we query it across every network that exposes it and assert that the returned value passes unit and freshness validation. If a network's upstream schema changes — say, Filecoin renames raw_power to quality_power — the probe fails, the mapping is flagged, and the affected series is paused rather than silently corrupted.
Rejecting Ambiguous Metrics
The most important design decision is what we refuse to publish. When a network exposes a metric whose definition we cannot determine — where we cannot confirm what the denominator is, what the freshness window is, or what physical quantity the number describes — we mark it schema_ambiguous and do not serve it as a canonical concept.
This is architecturally superior to shipping a corrupted signal. A wrong number confidently labeled is more dangerous than a missing one honestly marked. Every value we serve carries a freshness_verdict, and ambiguous mappings carry a schema_verdict of rejected so consumers can filter them programmatically.
Why Canonicalization Matters for AI Agents
Autonomous agents consume DePIN data to make infrastructure and trading decisions. An agent cannot be expected to reverse-engineer 89 different native schemas on the fly. By exposing 38 canonical concepts through a single REST API, we let an agent ask one question and get comparable, verifiable answers across every network it cares about.
The result is a data product where the integration cost is identical whether you are consuming one network or all 372 networks with live data served through our REST endpoints. That normalization layer — the 89-to-38 collapse, enforced by hourly self-tests and strict rejection of ambiguity — is the difference between a feed and a data product.
Query the canonical schema directly:
# List canonical concepts and their units
curl "https://api.kairossignal.com/v1/networks/akash" -H "X-API-Key: *"
Compare the same canonical concept across networks
curl "https://api.kairossignal.com/v1/compare?concept=GPU_UTILIZATION" -H "X-API-Key: *"
---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/networks, /v1/supply on the REST API.
Related reading: DePIN Intelligence guide · DePIN network data: 372 networks, 138 sources · how we read supply telemetry from 296 networks · the DePIN developer guide
Design-partner seats are capped at 20 at a lifetime-locked $199/mo (full API access, every published endpoint, MCP server, Bitcoin-anchored provenance). After seat 20 the price becomes $249/mo. Claim a design-partner seat → · See pricing---
Get Started With DePIN Intelligence
Kairos Signal provides verifiable, provenance-first telemetry for DePIN networks, including first-party supply data read directly from a network's own API or blockchain. Every value carries a verify_url you can check yourself, and each daily batch is Merkle-rooted and anchored to Bitcoin.
Every API response is signed with ed25519 and timestamped. You can prove what was served and when, months later. That is what we mean by provenance-first.
Related reading: DePIN Intelligence Guide · DePIN Telemetry · How to Query DePIN Data · DePIN Data Verification · Pricing