LIVE STATUS: /uptime·IOT · EDGE · CONNECTED DEVICES
DATA WITH RECEIPTS · ED25519 · RFC 3161 · KEYLESS MCP + REST·--:--:-- UTC
Home  /  IoT
VERIFIABLE DATA FOR DEVICE FLEETS · IOT · ROBOTICS · DePIN

Tamper-evident data for device fleets.

Signed, independently time-stamped data your machines can trust. Consume our live verified feeds, weather, GPS-integrity, air quality, marine, space weather, that a device verifies on-device before acting; or sign & time-stamp your fleet's own readings for tamper-evident proof anyone can check, even against us. One keyless API. Built for IoT, robotics & DePIN. Evidence, not a safety guarantee, your stack owns every decision.

I build devices / agents

Consume verified real-time feeds

Trusted live data your devices and agents consume and verify on-device before acting, weather & forecast, GPS-interference, air quality, marine, space weather. Every datapoint signed + provenance-stamped. Keyless to try; a free key when you're ready.

I run a device fleet / DePIN network

Sign & time-stamp your own device data

Make your fleet's readings tamper-evident: hash a reading on the device, we Ed25519-sign it and have it time-stamped by an independent RFC 3161 authority, and anyone can verify it later, even against us. Built for DePIN (weather stations, mapping, sensor networks). We'll wrap, sign & time-stamp your source in days.

THE PROBLEM

Edge devices act on data they can't independently trust.

A gateway, controller, or autonomous device pulls in world-data, the local forecast, the grid's carbon intensity, the air quality, whether GPS is being jammed nearby, and acts on it. But how does it know that value wasn't stale, swapped, or tampered in transit? Most feeds arrive as a bare number with nothing the device can check. The device trusts the pipe.

The other direction is just as weak: a device records its own sensor reading, but that telemetry isn't independently provable later. When a warranty claim, a compliance audit, or a dispute asks "what did this sensor read, and when?", a value in a log you control proves nothing, it could have been written after the fact. What holds up is a record signed and timestamped by a third party at the moment it existed, that anyone can re-check without trusting you, or us.

WHAT WE PROVIDE

Verified data in. Signed proof out. Both keyless.

Two directions, one substrate, the same infrastructure that signs and time-stamps every datapoint we publish.

Direction 1 · world-data into devices

Verified world-data your device can check before it acts

Devices and gateways consume our live feeds over keyless MCP / REST and verify each datapoint's Ed25519 signature on-device before acting, so an edge device trusts the data isn't stale or tampered, not just the connection it came over.

  • Live feeds device builders actually use, current_weather, weather_forecast, energy_grid, grid_carbon, air_quality, gps_interference, space_weather, flood_forecast, and more.
  • Every datapoint is signed over its exact bytes and carries per-datapoint provenance, source, source URL, and the exact measurement timestamp.
  • The same open-source verifier runs on-device or on the gateway, no network round-trip needed to check a signature.

Direction 2 · signed telemetry out

An RFC 3161 timestamped proof your reading existed, unchanged, at a time

A device hashes its own sensor reading locally and sends just the hash to our notary API, and gets back an independently time-stamped proof that the reading existed unchanged at a time. Tamper-evident evidence for disputes, compliance, audits, and warranty. Hashes only, your data never leaves the device.

  • One POST /v1/anchor with a 64-hex SHA-256, we Ed25519-sign it and have it time-stamped by an independent RFC 3161 authority (instant, no account).
  • Privacy by construction: the underlying reading, file, or payload stays entirely on your side, there is nothing for us to read, store, or leak.
  • Anyone can verify the proof independently later, even against us. Proof of existence-at-a-time, not a claim about the reading's accuracy.

Same substrate, same envelope as everything else we publish, and the same one our robotics / ROS 2 package rides on. Keyless to start: npx dynamicfeed-mcp for agents and gateways, or a plain POST /v1/batch for everything else.

LIVE, RIGHT NOW

Three device-relevant feeds, signed & live.

Each card below is a live reading fetched in your browser from POST /v1/batch, the exact call an edge device makes. Every response is Ed25519-signed and provenance-stamped; a device verifies that signature before acting.

live · POST /v1/batch · Ed25519-signed

current weather · Sydney

17.1°

Feels 18.8° · humidity 87% · Mainly clear

source Open-Meteo · sample

air quality · Sydney

45

US AQI · Good · PM2.5 8.3 µg/m³

source Open-Meteo Air Quality · sample

GPS integrity · baltic

52.6%

degraded fraction · 20/38 aircraft · sev high

derived from live ADS-B (GPSJam) · sample

Each reading is signed over its exact bytes, verify any signature yourself on /proof or with the open-source verifier.

how a device uses this

A gateway fetches the reading, checks the Ed25519 signature against the published key on-device, and only then feeds it to its control logic. If the signature doesn't verify, stale, swapped, or tampered, the device knows not to trust it. The signature proves the datapoint existed, unchanged, as we reported it at that time; it is not a claim that the value is objectively true, and it is evidence, not a safety guarantee, the device's own stack owns the decision.

EDGE QUICKSTART

Copy-paste, runs on the device today.

No key, no signup. These hit the real endpoints on dynamicfeed.ai as-is, one to pull a signed datapoint in, one to time-stamp a reading hash out.

1

Fetch a signed datapoint

One keyless MCP or REST call returns the reading plus an Ed25519 signature block over its exact bytes. The device acts on what it can check.

2

Verify the signature on-device

Drop the signature field, canonicalize the rest (JSON, keys sorted, compact), and check it against /.well-known/keys. Use the open-source verifier or try it live at /proof, no network round-trip needed.

3

Time-stamp your own reading

Hash a sensor reading locally and POST /v1/anchor the digest, never the data, for an RFC 3161 timestamped, tamper-evident proof it existed at time T. See the notary quickstart.

SHELL · 1) fetch a signed datapoint · POST /v1/batchCOPY
# a gateway pulls a signed reading the edge device acts on
curl -s https://dynamicfeed.ai/v1/batch \
  -H "Content-Type: application/json" \
  -d '{"calls":[{"tool":"air_quality","args":{"city":"Sydney"}}]}'

# → returns the datapoint + a top-level Ed25519 "signature" block.
# Verify it on-device against /.well-known/keys BEFORE acting on it, 
# canonical = the response WITHOUT its "signature" field, keys sorted, compact.
# open-source verifier: github.com/dynamicfeed/df-verify (Python + JS), or /proof
SHELL · 2) time-stamp your reading's hash · POST /v1/anchorCOPY
# 1) hash the sensor reading locally, your data never leaves the device
DIGEST=$(printf '{"device":"sensor-7","temp_c":17.1,"t":"2026-06-14T04:00:00Z"}' | shasum -a 256 | cut -d' ' -f1)

# 2) time-stamp JUST the digest, keyless, hashes only
curl -s https://dynamicfeed.ai/v1/anchor \
  -H "Content-Type: application/json" \
  -d "{\"digest_hex\":\"$DIGEST\"}"

# → status:"timestamped" + a signed RFC 3161 timestamp token you store on the device.
# An independent RFC 3161 authority time-stamps the digest instantly (no account),
# durable, independently verifiable evidence the reading existed unchanged at a time, verifiable by anyone.
WHO IT'S FOR

Devices and fleets that act on data, and produce it.

industrial IoT · SCADA

Ground the controller, prove the reading

Feed plants and controllers verified world-data they can check on-device, and time-stamp process readings for a tamper-evident record when an audit or incident review asks what a sensor reported, and when.

fleet & asset telematics

An independent record per asset

Time-stamp a hash of a vehicle or asset reading so a maintenance, warranty, or insurance dispute has a third-party-signed record neither party controls, evidence, not a self-report.

environmental & smart-city sensors

Cross-check and attest

Pull signed air-quality, weather, and flood feeds to corroborate a local sensor, and time-stamp your own readings so a published environmental record is independently verifiable.

energy · DER · VPP devices

Dispatch on data you can verify

Inverters, batteries, and demand-response devices consume signed energy_grid and grid_carbon readings, and verify the signature on-device before acting on a dispatch or carbon signal.

agritech

Verified conditions, time-stamped harvest data

Field gateways pull signed weather and drought feeds, and time-stamp a hash of yield or soil readings for a record that holds up for a buyer, an insurer, or a subsidy claim.

drone · robotics · humanoid edge

A signed go/no-go before a machine acts

Before a drone flies or a humanoid robot steps into a shared workspace, get a per-class signed go / caution / no-go from POST /v1/awareness, or the presets /v1/preflight (drone), /v1/road (AV) and /v1/humanoid (bipedal, tuned for topple, slip & ice underfoot). Log the signed verdict the system acted on. Evidence, not a safety guarantee, your stack owns the decision.

INTEGRATIONS

Drop-in clients for the stacks your devices already run.

Four open reference integrations sit on the same keyless endpoints, pull a signed datapoint in, verify it on-device, time-stamp a reading out. Each is a worked example to validate on your own hardware / platform (we can't flash an MCU or run Home Assistant for you); each is explicit that a signature is proof a datapoint existed unchanged at a time, evidence, not a safety guarantee. Source on github.com/dynamicfeed.

edge SDK kit · ESP32 · pi · micropython

Fetch → verify on-device → time-stamp

Three reference clients that do one thing well: fetch a signed datapoint, verify the Ed25519 signature on the device itself against a key you pin in firmware, and optionally time-stamp a hash of a local reading with an independent RFC 3161 authority. The Raspberry-Pi / Linux client is the flagship (full float-exact verify, runnable today); the ESP32 (Arduino C++) and MicroPython clients verify integer/string payloads + store timestamped receipts on-device, with float-bearing payloads best-effort. Honest constraint: not for an 8-bit Arduino Uno, verify on a Pi-class gateway and fan out.

clients/edge ↗·Python · C++ · MicroPython

home assistant · rest sensors

Verifiable data into your smart home

A read-only bridge using Home Assistant's built-in REST sensors, no custom component, no API key. Pulls outdoor weather, air quality, AU/UK grid_carbon, and US energy_grid into sensor.dynamic_feed_* entities, surfacing each value's provenance + freshness as attributes so an automation can refuse to act on stale data. It surfaces the signature block for out-of-band verification; HA's Jinja can't verify Ed25519 itself, and the integration controls no device and makes no safety decision.

node-red · flow node

A signed datapoint in any flow

A Dynamic Feed node for Node-RED: give it a tool name and an args object and it calls POST /v1/batch, putting the full Ed25519-signed envelope on msg.payload and convenience fields on msg.dynamicfeed. Zero runtime dependencies (uses Node 18+ global fetch); set the tool per message via msg.tool. Wire it to an inject, an MQTT topic, a dashboard, or a PLC bridge. Verify the signature on the Node-RED host (Pi-class), then pass the trusted result downstream.

packages/node-red-dynamicfeed ↗·node-red-contrib-dynamicfeed

mqtt · pub/sub bridge

Signed feeds onto your broker

A small poller that calls /v1/batch one tool per request and republishes the exact raw signed bytes to dynamicfeed/<tool> on any MQTT broker, so MQTT-native devices consume Dynamic Feed without speaking HTTP. One tool per batch keeps each payload independently verifiable; an included verify_subscriber.py re-canonicalizes and checks every message (VALID confirmed live, a 1-field tamper rejected). Env-configured tools/interval/QoS, never-hang timeouts, clean shutdown.

integrations/mqtt-bridge ↗·bridge.py + verify_subscriber.py

Copy-paste the snippet for your stack, each hits the real endpoints on dynamicfeed.ai as-is:

PYTHON · Raspberry-Pi / Linux SBC · fetch → on-device Ed25519 verifyCOPY
# pip install requests pynacl   (PyNaCl ships ARM wheels, installs on Raspberry Pi OS)
import json, base64, requests
from nacl.signing import VerifyKey

API = "https://dynamicfeed.ai"
r = requests.post(API+"/v1/batch", json={"calls":[{"tool":"air_quality","args":{"city":"Sydney"}}]}, timeout=20).json()
sig = r.pop("signature")                       # detach the signature block
msg = json.dumps(r, sort_keys=True, separators=(",",":")).encode()  # json-sorted-compact
jwks = requests.get(API+"/.well-known/keys", timeout=20).json()
pub  = base64.urlsafe_b64decode(jwks[sig["key_id"]] + "==")   # look key up by sig.key_id
VerifyKey(pub).verify(msg, base64.urlsafe_b64decode(sig["sig"] + "=="))  # raises if tampered
print("VALID", r["results"][0]["data"]["us_aqi"])    # act only after this passes
# full client (+ RFC 3161 timestamp of a local reading): clients/edge/raspberry-pi/
YAML · configuration.yaml · Home Assistant REST sensorCOPY
# keyless REST sensor, value + provenance/freshness as attributes
rest:
  - resource: https://dynamicfeed.ai/v1/batch
    method: POST
    headers: {"Content-Type": application/json}
    payload: '{"calls":[{"tool":"grid_carbon","args":{"region":"nsw"}}]}'
    scan_interval: 600
    sensor:
      - name: "Dynamic Feed Grid Carbon Intensity"
        value_template: "{{ value_json.results[0].data.carbon_intensity_g_per_kwh }}"
        unit_of_measurement: "gCO2/kWh"
        json_attributes_path: "$.results[0].data"
        json_attributes: ["provenance", "freshness", "method", "derived"]
# AU grid_carbon is DERIVED from live AEMO dispatch (not an official measurement);
# the tool says so in its own fields. Full config: integrations/home-assistant/
SHELL + JSON · Node-RED node install & flow importCOPY
# 1) install the node into your Node-RED user dir, then restart (Node 18+, zero deps)
npm install /path/to/packages/node-red-dynamicfeed   # or, once published: node-red-contrib-dynamicfeed

# 2) in the editor: drop a "Dynamic Feed" node, set Tool + Args, wire to a debug node.
#    Per-message: leave Tool blank and set msg.tool + msg.payload (args) upstream.
# the node sets msg.payload to the full SIGNED envelope:
{ "calls": [ { "tool": "current_weather", "args": { "city": "Sydney" } } ] }
# → msg.payload = { count, results:[{tool,ok,data}], signature{alg,key_id,sig} }
# → msg.dynamicfeed = { tool, ok, data, signature }   (verify on the Pi-class host)
SHELL · MQTT bridge · poll → publish signed bytes → verify on subscriberCOPY
# pip install paho-mqtt requests pynacl
export MQTT_HOST=broker.example.com
export DF_TOOLS='current_weather:{"city":"Sydney"},air_quality:{"city":"Sydney"},grid_carbon'
export DF_INTERVAL_SEC=300
python bridge.py            # publishes RAW signed bytes to dynamicfeed/<tool> (one tool per batch)

# on any subscriber, re-canonicalize + verify the Ed25519 signature per message:
python verify_subscriber.py
# [verify] OK  dynamicfeed/air_quality: VALID (active key df-ed25519-6ca0de29113b)
# VALID = unaltered since we signed it; NOT a claim the value is correct.
WHAT "SIGNED & TIMESTAMPED" MEANS, IN PLAIN WORDS

Proof of existence, not a safety certification.

read this before you rely on it

Signing and RFC 3161 timestamping give you proof-of-existence-at-a-time and tamper-evidence: that a datapoint existed, unchanged, at a specific time, and that any later edit is detectable. They do not prove the datapoint is true or accurate, and we make no accuracy guarantee about an upstream source. This is not device management, not a safety system, and not a safety certification. It is evidence, not a safety guarantee, your device's own stack owns every decision. Hashes you time-stamp stay hashes: your sensor data never leaves the device.

THE FUTURE, HERE AND NOW

Fully automated. Run by AI, end to end.

No sales calls and no waiting. Mint a key and you are live in seconds, on any tier.