Roadmap
Ordered, and deliberately undated
A date on a roadmap is a promise, and a promise made by an undeployed protocol is worth what it costs to type. What is real here is the order, and the fact that each phase has a deliverable that is a decision rather than a feature.
Phases
-
I
Instrument shipped
The public design: the mechanism, every parameter with its bound, the fee table with its holes visible, and the open-problems list. This site.
- Mechanism published
- Parameters and bounds
- Open problems named
- Palette and hero derived and verified
-
II
Orbit next
The hook. A single pair, a single managed range, on a testnet, with the NAV guard designed before the code rather than after it.
- v4 hook: range management
- NAV deviation band
- Buffer accounting
- First external review
-
III
Ephemeris later
Mint, redeem and the locked class. Redemption under stress is the part that has to be specified here, not the part that is discovered later.
- Mint and redeem at NAV
- Buffer escalation rule
- Locked class and boost
- Redemption-under-stress spec
-
IV
Transit later
Intents and batching, which cannot ship before the solver set has rules. The rules are the deliverable; the router is the easy half.
- Solver registration and bonds
- Batch construction rule
- Gas abstraction
- Public settlement archive
-
V
Sidereal later
Tokenised equities, once the halt policy, the corporate-action path and the transfer-restriction question have answers rather than placeholders.
- Halt and closure policy
- Corporate actions
- Restriction compatibility
- Reference-price attestation
What is not on it
A token generation event, an exchange listing, a partnership, or a chain. Those appear on roadmaps because they are legible, not because they are load-bearing — and every one of them is a claim about somebody else's decision. The five phases above are entirely things this project can do to itself.