Roadmap
This is the docs-facing roadmap for Lyrasing’s build-time research and documentation work. It is not a launch schedule, date promise, governance roadmap, token roadmap, supported-asset roadmap, deployment announcement, or market-parameter disclosure.
Use this page to understand what to read, which research track owns each part of the documentation, and what still has to be true before the docs are complete enough to use as protocol-design infrastructure.
Documentation sequence
The documentation is staged as an ordering and dependency model:
| Order | Section | Why it comes here |
|---|---|---|
| 1 | Concept | Establishes the thesis, problem framing, and terminology baseline before deeper policy pages depend on it. |
| 2 | AVS-risk methodology | Defines observable inputs, exposure taxonomy, slashability timing, and LTV-adjustment posture. |
| 3 | LRT collateral framework | Turns the risk vocabulary into candidate-collateral review questions before any supported-list claim exists. |
| 4 | Slashing-insurance design | Defines coverage scope, capacity, trigger, claim, and payout language after exposure and collateral surfaces are named. |
| 5 | Looping / leverage | Adds recursive exposure policy only after collateral, liquidation, timing, and insurance inputs are reviewable. |
| 6 | Comparisons | Compares Lyrasing’s method with adjacent primitives without treating those protocols as integrations. |
| 7 | Contributors | Locks the review standard future docs and research updates should follow. |
Protocol research sequence
Protocol research should stay aligned with the docs. Each track owns a narrow decision surface and should avoid turning review language into live product claims.
| Track | Docs it maps to | Output |
|---|---|---|
| AVS exposure model | AVS-risk methodology | Observable inputs, exposure taxonomy, slashability timing, stale-input posture, and policy compression rules. |
| LRT collateral review | LRT collateral framework | Candidate-collateral checklist, backing and redemption review, oracle/liquidity posture, qualitative risk tiers, and supported-list boundary. |
| Slashing-insurance capacity | Slashing-insurance design | Coverage scope, trigger evidence, payout ordering, capacity constraints, and fail-closed language for unresolved slash surfaces. |
| Liquidation / loop policy | Looping / leverage | Recursive exposure states, unwind posture, loop compression triggers, and no-loop boundaries. |
| Oracle / observable input posture | AVS-risk methodology and LRT collateral framework | Source freshness, stale-input treatment, non-observable-input handling, and future oracle requirements without claiming an oracle implementation. |
| Source accuracy and review cadence | Contributors plus all methodology pages | Primary-source checks, access dates, changed-claim packets, and downgrade rules when a source no longer supports a claim. |
Complete enough to use
The docs are complete enough to use when they are stable as build-time docs, not when they imply a deployed protocol. The working standard is:
| Requirement | Done means |
|---|---|
| Deterministic sidebar | Every section is linked in the docs navigation with predictable order and searchable page text. |
| Source-backed claims | Protocol-mechanics claims are either supported by primary sources and access dates, or phrased as Lyrasing review questions. |
| No live-product ambiguity | Pages do not imply active markets, active integrations, supported collateral, wallet flows, reserves, oracle contracts, or launch parameters. |
| Static export health | The docs export to static HTML and text artifacts that can be served without a runtime application server. |
| Lighthouse / performance follow-up | Docs routes are measured under the project static-gzip baseline, with docs JS and route-level performance tracked as a remaining quality gate. |
| Contributor review standards | Future changes include changed pages, changed claims, source evidence, product-boundary checks, verification output, and risk-surface notes. |
Later work outside this slice
Some work belongs after the Phase 3 content tree is coherent:
- R3F and visual polish for the landing experience.
- Waitlist backend, attribution, rate limits, privacy posture, and storage.
- Deploy announcements and launch communications.
- Protocol implementation, contracts, oracle implementation, and parameter engines.
- Real supported-list records, product parameters, caps, LTVs, fees, reserves, and market configuration.
Until those scopes exist, this roadmap stays an ordering tool for documentation and protocol research.