Why
We build on this chain and we keep up with it fine. The issue isn't speed, it's that we're always reacting — the first signal that something changed is the merged diff or the live runtime, so preparation can only start once the change already exists.
A published statement of what's coming would let us prepare in advance instead. That's the whole ask: a heads-up. What's landing, what's in it, and whether it breaks anything.
Machine-readable, so agents can consume it on our side without anyone writing prose for us.
How it gets written
By the agents writing the chain code, as they write it. An agent implementing a change already knows what it's building, what it touches and whether it breaks anything — it records that in ROADMAP.md in the same PR, and updates the status as the change moves toward release.
No separate bot, no scraping, no inference from labels or tags. The people (and agents) with the knowledge write it down at the moment they have it.
Status
proposed → in_progress → merged_unreleased → staged_for_release → live_on_mainnet
merged_unreleased is the important one for us: it says the code is on main but is still WIP and not yet heading out, so we can start reading it without treating it as final. staged_for_release is the signal to actually get ready.
We track first real-world use ourselves — that's our job, not yours.
Shape
Deliberately loose. A fenced block downstream agents can parse, with only the fields worth committing to:
# ROADMAP.md
releases:
- name: v439
status: staged_for_release
announcement: |
Targeting mainnet ~2026-08-04. Collateral drain-rate fix plus two new
selective-metagraph fields. One breaking change for indexers — see below.
items: [miner-collateral-drain-fix, metagraph-field-77]
items:
- id: hook-emitted-events
title: Events emitted from scheduler / on_initialize / coinbase hooks
status: live_on_mainnet
breaking: true
touches:
events: [NetworkAdded, SetChildren, RootClaimed, WeightsSet]
notes: |
These carry no extrinsic_id and no call_id, so anything joining events to
extrinsics needs to handle their absence.
- id: miner-collateral
title: Miner registration collateral
status: live_on_mainnet
breaking: false
touches:
storage: [MinerCollateral, ColdkeyMinerCollateral, CollateralLockShare]
events: [CollateralLocked, MinCollateralSet]
notes: |
Alpha / TotalHotkeyAlpha include locked collateral; withdrawable = alpha − locked.
The per-tempo drain decrements MinerCollateral.locked without emitting anything,
so it's only visible as a storage diff.touches is the part that saves downstream the most time — knowing which storage items and events a change lands on is usually enough to scope the work before the code is even final. notes is free text; anything that would otherwise have to be reverse-engineered from the diff belongs there.
Spec versions are deliberately absent — they bump on every merge, so they aren't a stable thing to plan against. Releases are.
Ask
Publish ROADMAP.md at the repo root, written by the agents doing the work as part of their PRs, with a block roughly like the above. When a release is coming, say so in releases[].announcement and flag anything breaking.
Why
We build on this chain and we keep up with it fine. The issue isn't speed, it's that we're always reacting — the first signal that something changed is the merged diff or the live runtime, so preparation can only start once the change already exists.
A published statement of what's coming would let us prepare in advance instead. That's the whole ask: a heads-up. What's landing, what's in it, and whether it breaks anything.
Machine-readable, so agents can consume it on our side without anyone writing prose for us.
How it gets written
By the agents writing the chain code, as they write it. An agent implementing a change already knows what it's building, what it touches and whether it breaks anything — it records that in
ROADMAP.mdin the same PR, and updates the status as the change moves toward release.No separate bot, no scraping, no inference from labels or tags. The people (and agents) with the knowledge write it down at the moment they have it.
Status
merged_unreleasedis the important one for us: it says the code is onmainbut is still WIP and not yet heading out, so we can start reading it without treating it as final.staged_for_releaseis the signal to actually get ready.We track first real-world use ourselves — that's our job, not yours.
Shape
Deliberately loose. A fenced block downstream agents can parse, with only the fields worth committing to:
touchesis the part that saves downstream the most time — knowing which storage items and events a change lands on is usually enough to scope the work before the code is even final.notesis free text; anything that would otherwise have to be reverse-engineered from the diff belongs there.Spec versions are deliberately absent — they bump on every merge, so they aren't a stable thing to plan against. Releases are.
Ask
Publish
ROADMAP.mdat the repo root, written by the agents doing the work as part of their PRs, with a block roughly like the above. When a release is coming, say so inreleases[].announcementand flag anything breaking.