Milestone 6: Documentation and Papers
Milestone 6 closes the program with finished documentation for the whole Skyhook ecosystem and the publication of the research produced along the way. Its acceptance criterion is simply that reviewers can view and verify the deliverables, which a reader of this site is in effect already doing. Documentation is funded as a milestone because infrastructure without it can’t earn trust, integration or liquidity at the scale the program aims for.
Three audiences
The same facts have to reach three audiences in different forms. Non-technical reviewers need explanations of the mechanism they can follow end to end, the register of this site. Developers need the code behind every claim, interface specifications with exact field layouts, and worked examples with real transaction IDs. Researchers need papers with proofs, precise theorem statements and explicit lists of assumptions. Unfunded documentation typically serves the first audience partly and the others not at all; the milestone budget pays for all three.
Scope and testing
The documentation covers the whole mechanism: rollups and finality, with their trust assumptions, the swap lifecycle with every exit, both liquidity modes and who holds pricing authority in each, note anatomy including the Ironwood transition, the settlement computer and its gas model, the economics of spreads, operational risks and their mitigations, and the roadmap itself, with a glossary and references. Completeness is measured by a simple test: every technical claim in the grant proposal must lead to a page that explains it, and a claim that doesn’t indicates a missing page rather than acceptable brevity.
The documentation is also treated as a set of testable assertions. Every cross-reference must resolve, with the build failing on any break; every cited transaction ID and block height must trace to a real run; every gas figure must come from a measured run rather than memory; and worked examples run against live networks rather than describing hypothetical flows. This turns reviewing the documentation into verification rather than editing, which matches the milestone’s acceptance criterion.
Versioning and maintenance
The site is versioned together with the implementation: every release of the system has a matching state of the documentation, and changes to interfaces, opcodes, gas schedules or pools each include the documentation update in their definition of done. After the program ends, maintenance passes to named maintainers with written responsibility, an update cadence tied to network upgrades, and an issue process for reports from the community. Without this, a proposal site would become a historical document within one upgrade cycle.
Research publication
Research runs alongside the documentation rather than after it. The principal paper has been submitted and is available on IACR ePrint. Findings produced during the program, on finality, feasibility, proofs of new primitives and constructions the milestones require, go through the same pipeline: from internal technical notes, written with complete proofs from the start, to public preprints archived regardless of review timelines, and then to peer-reviewed cryptography and systems venues suited to each result. Feedback from review flows back into the implementation and the documentation. Every lemma the implementation depends on ends up in citable form, because a result that hasn’t been described can’t be audited by others, and an unaudited result can’t anchor trust.
Acceptance
Verification is designed to be carried out by reviewers directly. They inspect the documentation site and confirm that every mechanism, milestone and claim leads to a page; they follow the references to the code and confirm that the cited behavior exists; and they read the papers and confirm that the theorems match the assumptions the implementation makes. No expert gatekeeping is involved, which is why the grant phrases the criterion as being able to view and verify the deliverables.
Status
Done
The documentation deliverable is substantially this site: the mechanism sections, the roadmap, the glossary and the references are complete, and the build fails on any broken cross-reference. The principal paper has been submitted and is cited, and the beta’s forum thread provides public, independent third-party operation with reported results. Both tracks need completion rather than a start.
Remaining
Final polish continues across the site, bringing every page to a uniform standard of completeness and accuracy. The research produced during the program, on finality, feasibility and new primitives, is still to be published at appropriate venues. The milestone closes with reviewers verifying, across all milestones, that the deliverables can be viewed and checked.