Roadmap: What Gets Built
The Skyhook roadmap is the funded program of work that completes the system described in the rest of this site. It consists of six milestones over about thirty-nine weeks, ordered so that each builds on the ones before it. Each milestone has its own budget and deadline, and each is accepted only when reviewers, not the team, can operate the result themselves: completing a swap in a browser, building a program in an interface, or confirming that a key is absent from transaction data.
The timeline and budgets above are read directly from the official application. The total budget covers compensation, hardware and services for the whole period; the Budget page gives the breakdown. The plan is revised only when a milestone fails acceptance, never merely because time has passed.
Sequencing
The milestones are ordered by dependency rather than by how impressive each would look:
- The reverse direction comes first because every later deliverable assumes that value can move both ways.
- Programmability follows because privacy circuits and mobile bindings both build on swaps that can execute programs.
- Full privacy changes settlement semantics that the mobile and liquidity work must then respect.
- Mobile needs the full set of transfers to be stable before wallets integrate it.
- Self-serve liquidity comes late because a standard should describe finished behavior.
- Documentation and papers close the program because they must cover everything that was built.
Each milestone page states its prerequisites explicitly, and dependencies only ever point to earlier milestones, so partial progress remains meaningful even if the schedule slips.
Budget allocation
Budgets follow engineering risk rather than the amount of code. Full privacy receives the largest allocation because circuit engineering carries the most uncertainty, and the reverse direction the smallest because its settlement machinery already exists. Mobile and programmability sit in between, with substantial but bounded unknowns, while documentation and liquidity standardization cost less because they formalize operations that already work.
Compensation is the largest part of every milestone. Hardware and services pay for build machines and RPC access across the program. The cost structure is that of a research and engineering program rather than a product company: nothing is spent on marketing, sales or token incentives.
Acceptance
Every milestone defines acceptance as something a reviewer can do directly. Committee members perform swaps in browsers, construct programs in interfaces, inspect transactions for absent keys, operate wallets on devices, integrate against published standards, and read these pages and their references. Proxy measures such as lines of code, test counts or demonstration videos don’t count, because none of them shows that a non-team member can reproduce the result; each milestone page describes the operation precisely enough to attempt it.
Evidence
Claims on these pages point to checkable artifacts wherever they can. Transaction IDs refer to real runs on test networks, gas figures to measured profiles rather than estimates, code to the implementation at pinned revisions, and forum threads to independent third-party operation. Each milestone’s Status section separates what is built, with evidence, from what remains, stated plainly. No milestone claims partial credit for unfinished deliverables.