Testnet & Roadmap

Overview

This page is intentionally separate from the protocol-spec story. Testnet availability, supported networks, and public roadmap sequencing are operational matters that can change faster than the underlying architecture.

Use the lightpaper and core developer docs for protocol design. Use this page for environment readiness, trial scope, and rollout context.

Testnet Scope

A test deployment may expose only a subset of the full architecture. Supported LP families, borrow assets, oracle coverage, and liquidation tooling can all be narrower on testnet than on an eventual production deployment.

• • Verify the active network, contract registry, and supported pool set for the current environment.
• • Expect mocked assets, restricted venue coverage, and shortened operational loops.
• • Treat testnet behavior as an evaluation environment, not as a final production promise.

How to Evaluate

The most useful way to test Avana is to walk the canonical flow: deposit an eligible LP position, confirm spoke-level valuation, observe aggregate borrowing capacity, borrow from the Hub-side liquidity layer, and then inspect health monitoring and repayment paths.

If a test deployment includes points, quests, or other campaigns, those should be treated as separate operational features rather than as evidence of the protocol's core collateral model.

Roadmap Framing

Roadmap statements should be interpreted as directional priorities: broader LP-family coverage, stronger oracle support, deeper liquidation tooling, and more refined risk governance. They should not be read as fixed launch dates or immutable network promises unless separately announced.

Campaigns & Status

Any active incentives, points programs, or network-specific rollout details should be published as campaign documentation or release notes. Keeping those details separate from the core protocol narrative makes the developer docs more stable and easier to trust.