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.
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.
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/anchorwith 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.
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.
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.
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.
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.
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.
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.
# 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) 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.
Devices and fleets that act on data, and produce it.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 (+ RFC 3161 timestamp 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 (active key df-ed25519-6ca0de29113b) # VALID = unaltered since we signed it; NOT a claim the value is correct.
Proof of existence, not a safety certification.
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.
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.