Amanat

Amanat

Signed weather intelligence that a contract acts on by itself.

*Signed*, not "verified": the network's own verified: true cannot be checked from outside (bug report), so every answer here carries an Ed25519 signature over the fields a contract settles on, and anyone can check it with Node and nothing else:

node -e 'const c=require("node:crypto");fetch("https://amanat-miner.vercel.app/forecast?lat=10.32&lon=123.89&hours=6").then(r=>r.json()).then(({attestation:a})=>console.log(c.verify(null,Buffer.from(a.canonical),c.createPublicKey({key:Buffer.from(a.public_key,"base64"),format:"der",type:"spki"}),Buffer.from(a.signature,"base64"))))'

The key it checks against is the one published at /.well-known/amanat.json.

An *amanat* is a message entrusted to be carried — and, in the language of the old telegraph offices, the dispatch itself. That is the whole shape of this project: a miner sends the amanat, a scoring module tests it, and a contract carries it out without anyone deciding anything by hand.

Built for Telegraph Hackathon Season I. One codebase, three entries:

Live: amanat-miner.vercel.app — read a storm risk for any point, no wallet, no sign-up. It is the same call the contract makes before it spends anything.

In one line, from any MCP client: npx -y amanat-mcp — published to npm and listed in the official MCP registry as io.github.PugarHuda/amanat.

In three minutes: the deck · the film (84 s, cut from live sessions — no mockups) · /api/jobable, which measures how many intents are closed to on-chain jobs, how many are open, and how many cannot be audited at all because their leader publishes its registration at 127.0.0.1. Add ?intent=STORM_ALERT for a verdict on your own.

The three problems this is built around

Everything here comes from measuring the live network rather than guessing at it. The numbers below are reproducible with the scripts in this repo.

1. Deterministic intents are scored as if they were prose. In epoch 240 the rank-1 miner on WEATHER_CHECK scored 0.0206 and on STORM_ALERT 0.0067. The miners are not bad; every scoring module on the network compares text, and those miners answer with numbers. A leaderboard built from those scores is noise — and routing follows the leaderboard.

2. The on-chain rail is real but unused. The Diamond answers getJobBasePrice() with 1000000 and, on 21 August, carried 139 miner registrations against 6 ERC-8183 jobs in its entire lifetime — the last two by a single participant, on 17 August. In a 77-hour window there were 44 MinerRegistered events and 2 JobCreated. Meanwhile the organisers name on-chain intelligence pipelines as the highest-value thing to build.

Read again on 31 August: 341 miner registrations, and still only 14 jobs. Eight of the fourteen are ours. Five settled; the last three have not moved.

3. Almost no miner can receive a job at all. A job hands the node raw OnChainData arrays; without an on_chain.request block in its YAML the node cannot turn those into an HTTP call. npm run audit fetches every registered YAML and checks. On 31 August: of 125 live miners, 29 declare an `on_chain` block at all, and a name-hashable intent has between one and three job-able miners — STORM_ALERT has exactly one, and it is this one. That is the bottleneck under problem 2, and it has loosened rather than closed: on 21 August there were 63 live miners and every name-hashable intent had a single job-able miner.

What the network actually looks like (read from /api/epochs, /api/validators and the Diamond, 21 August): epochs run hourly on testnet, not the 24 hours the docs describe. Each one scores 70 results across 17 intents and 29 of the 66 registered miners — more than half are never scored at all. There is one active validator, telegraph-node-1, so the 43-of-64 BFT threshold is a mainnet property, not something running today.

The shape held; the size did not. At epoch 294 on 30 August the network scored 242 results across 42 intents and all 125 live miners, and epochs had stopped being hourly — the last five landed 3 to 9 hours apart. Still one validator.

Track 1 — the miner

miner/server.mjs reads three free, keyless sources and returns every answer in two shapes at once. Open-Meteo's weather model gives the air; its marine model gives significant wave height, which is the thing that actually stops a ship and the one figure the shipping-lane board was missing; and GDACS gives every active named tropical cyclone on Earth with its position and maximum wind, so a reading under Tropical Storm Dolly says so by name rather than reporting "38 km/h wind". Storm risk is the worst of wind, gusts, rain, waves and cyclone proximity — a 4 m sea or a typhoon overhead reaches the ceiling on its own.

{

"summary": "Weather forecast for -6.20, 106.85: the temperature is 27.8 °C (82 °F) and it feels like 32.3 °C, humidity 73%, Clear sky, cloud cover 0%, wind 4.4 km/h (1.2 m/s) from the south-east, gusts 11.9 km/h, precipitation 0.0 mm (2% chance of rain), valid at 2026-08-30T17:00Z. … Storm risk is low (0.132); across 51 ensemble runs it ranges 0.08 to 0.14, 0% of them over the trigger.", "temp_c": 27.8, "wind_kmh": 4.4, "gust_kmh": 11.9, "precip_mm": 0, "wave_cm": 0, "cyclone_name": null, "cyclone_km": 0, "risk": 0.132, "breach": false, "valid_at": "2026-08-30T17:00Z", "source": "open-meteo", "risk_band": { "model": "ecmwf_ifs025", "members": 51, "p10": 0.076, "p50": 0.104, "p90": 0.14, "max": 0.164, "breach_probability": 0 }, "attestation": { "algorithm": "ed25519", "sha256": "9e991dc5…", "signature": "B3dtTlG1…", "public_key": "MCowBQYDK2VwAyEAJf1zypC6…", "key_persistent": true } }

Abridged: a live response carries 36 fields. The rest are the ones a report carries and a contract ignores — humidity, dew point, wind direction, cloud cover, chance of rain, a two-day high and low, sea level, the named cyclone and its distance — plus the signed canonical payload and Open-Meteo's attribution. curl -s -X POST https://amanat-miner.vercel.app/forecast -H 'content-type: application/json' -d '{"lat":-6.2,"lon":106.85,"hours":0}' for the whole thing.

The sentence is what a text-comparing scorer can grade. The scalars are what Amanat.sol acts on, mapped through on_chain.fields in amanat-miner.yaml. Serving only one of the two is why the network currently has the gap it does.

The YAML also carries a complete on_chain.request block, which is what makes the miner reachable from a job at all, and declares Open-Meteo's real quota so the node refuses a request that would exhaust it *before* charging the caller.

npm run miner        # http://127.0.0.1:8787

node miner/test.mjs # self-check, hits the real upstream

Hosting it

The miner has no dependencies, so the image is the runtime plus one file.

docker build -t amanat-miner miner/ && docker run -p 8080:8080 amanat-miner

fly deploy -c miner/fly.toml # or cd miner && vercel deploy --prod # serverless, via miner/api/*

Whichever you pick, the host has to be live *before* registerMiner: the node sandbox-tests every declared endpoint against the real upstream, and a registration whose YAML fails validation is rejected terminally rather than retried.

Track 2 — the scoring module

scorer/ is a no_std Rust module compiled to wasm32-unknown-unknown: 15.5 KB, zero imports, exporting alloc, dealloc, rank_answer and breakdown_answer.

It reads the *quantities* out of an answer and grades them as measurements: 38.2 °C, 100.8 F and 311.35 K are one reading; 10 m/s and 36 km/h are one wind speed; being 0.3° out is right and 30° out is wrong. Text overlap stays, but only to carry the non-numeric part of an answer.

Two rules do most of the anti-gaming work:

• A number the question already stated earns nothing when it comes back. "Will it exceed 40 °C?" answered with "40 °C" is the prompt, not a reading — unless the ground truth also says 40.
• Committing beats covering. Listing every candidate value is charged for, so a hedged answer cannot outscore a decision.

Every float operation is + - * / and comparison, which IEEE-754 defines exactly, so two validators on different hosts return identical bits.

npm run build:scorer

npm run bench # against the real champion binaries npm run attacks cd scorer && cargo test # 27 tests, native

Measured on scorer/bench.json (38 good/bad cases across 31 intents, 14 attacks) against champion binaries downloaded from their published wasm_url, re-run 31 August:

Stage 2 needs both bars — margin and ordering wins at least matching the champion — so the wins column matters as much as the margin.

The top row is the one to read first: registration 1265, the module that took the GAME_RESULT slot back off us after forty minutes, beats this module on this corpus. It is a good module. The three seated on the weather intents are not, and that is the gap this project is about.

Reproducing this table needs one step the repo cannot do for you. scorer/champions/*.wasm is gitignored — they are other people's binaries, some of them 25 MB — so a clean clone has nothing to compare against and npm run bench will report only our own. Fetch them first from the wasm_url each registration publishes at https://devnode.telegraphprotocol.com/api/wasm and drop them in scorer/champions/. npm run attacks reads scorer/target/…/amanat_scorer.wasm, so it wants npm run build:scorer first.

Read the rest honestly: this corpus is ours, and it says the approach works on the cases we can see, not that it wins the protocol's own hidden fixtures.

Widening the corpus from 20 cases to 38 is what found the real bugs. It exposed that "812.4 million" parsed as 812.4 while "812.4M" parsed correctly, that a correct paraphrase omitting a figure scored below a wrong answer that quoted it, and that "not a human" was being read as a negative verdict on an AI-detection question. Each of those was a wrong rule, not a missing special case.

The gate nobody talks about

Beating the champion's margin is not sufficient on an intent that carries traffic: the node also checks that your module orders *real