Edge devices and fleets act on data — and produce it. Dynamic Feed is the layer they plug into, both directions: verified world-data into your devices (weather, energy grid, air quality, GPS-integrity, space weather and more) that a device can verify on-device before acting, and signed telemetry out — anchor a hash of a sensor reading to Bitcoin for a tamper-evident proof it existed unchanged at a time. One keyless MCP + REST call; the same substrate as our ROS 2 robotics package and on-device open-source verifier. Evidence, not a safety guarantee — your device's own stack owns every decision.
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.
Two directions, one substrate — the same infrastructure that signs and anchors every datapoint we publish.
↓ Direction 1 · world-data into devices
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.
current_weather, weather_forecast, energy_grid, grid_carbon, air_quality, gps_interference, space_weather, flood_forecast, and more.↑ Direction 2 · signed telemetry out
A device hashes its own sensor reading locally and sends just the hash to our notary / anchor API — and gets back a Bitcoin-anchored 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.
POST /v1/anchor with a 64-hex SHA-256 — we Ed25519-sign it and commit it toward a Bitcoin block via OpenTimestamps (free, no wallet).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.
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.
current weather · Sydney
17.1°
Feels 18.8° · humidity 87% · Mainly clear
air quality · Sydney
45
US AQI · Good · PM2.5 8.3 µg/m³
GPS integrity · baltic
52.6%
degraded fraction · 20/38 aircraft · sev high
Each reading is signed over its exact bytes — verify any signature yourself on /proof or with the open-source verifier.
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.
No key, no signup. These hit the real endpoints on dynamicfeed.ai as-is — one to pull a signed datapoint in, one to anchor a reading hash out.
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.
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.
Hash a sensor reading locally and POST /v1/anchor the digest — never the data — for a Bitcoin-anchored, tamper-evident proof it existed at time T. See the notary quickstart.
# 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
# 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) anchor JUST the digest — keyless, hashes only curl -s https://dynamicfeed.ai/v1/anchor \ -H "Content-Type: application/json" \ -d "{\"digest_hex\":\"$DIGEST\"}" # → status:"pending" + a proof_ots_b64 you store on the device. # ~1 block later, POST /v1/anchor/upgrade to fetch the Bitcoin attestation — # a permanent proof the reading existed unchanged at a time, verifiable by anyone.
Feed plants and controllers verified world-data they can check on-device, and anchor process readings for a tamper-evident record when an audit or incident review asks what a sensor reported, and when.
Anchor 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.
Pull signed air-quality, weather, and flood feeds to corroborate a local sensor, and anchor your own readings so a published environmental record is independently verifiable.
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.
Field gateways pull signed weather and drought feeds, and anchor a hash of yield or soil readings for a record that holds up for a buyer, an insurer, or a subsidy claim.
Query a signed gps_interference reading or a per-class awareness verdict before a flight, and log the signed indicator the system acted on — auditable after the fact.
Four open reference integrations sit on the same keyless endpoints — pull a signed datapoint in, verify it on-device, anchor 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
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 anchor a hash of a local reading to Bitcoin. 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 + anchor 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.
home assistant · rest sensors
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 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.
mqtt · pub/sub bridge
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.
Copy-paste the snippet for your stack — each hits the real endpoints on dynamicfeed.ai as-is:
# 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 (+ Bitcoin anchor of a local reading): clients/edge/raspberry-pi/
# 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/
# 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)
# 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 (key df-ed25519-4cb32e72f333) # VALID = unaltered since we signed it; NOT a claim the value is correct.
Signing and Bitcoin-anchoring 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 anchor stay hashes: your sensor data never leaves the device.
Tell us what your devices consume and what they produce, and we'll scope it on a short call — feeds in, signed proofs out. No card details, no checkout; we agree the scope and price first.