Products, Policies & Plan Families
OmegaX coverage runs as a layered health-plan system rather than a one-off policy record.
That difference matters. The goal is not to mint a single policy artifact and hide the rest in operator workflow. It is to make products, policy rights, premiums, and claims legible parts of the same plan system.
Use this page when you want the generic coverage model before reading the bounded Genesis Protect launch pages.
The current protocol model supports coverage objects, premium truth, reserve-aware claims, and policy-series semantics. Specific public product availability still depends on posted reserve, published terms, and staffed review readiness.
Genesis Protect launch pack
For the current Genesis Protect Acute launch wording, use the dedicated pack:
- Genesis Protect Acute
- Genesis Protect Availability
- Genesis Protect Sponsor Cohorts
- Genesis Protect FAQ
This page stays at the generic coverage-model layer.
The coverage structure
OmegaX coverage can be understood as:
- Health Plan
- Policy series
- Member policy position
This allows one plan to support multiple offerings while still sharing the same broader policy, reserve, and oracle boundaries.
| Layer | What it answers | Why readers should care |
|---|---|---|
| Health Plan | What reserve, trust, and operating boundary governs the product family? | It keeps coverage from becoming a loose set of disconnected promises. |
| Policy series | Which terms, payment rules, and claim semantics apply to this offering? | It makes product variations comparable over time. |
| Member policy position | Who holds rights under the series, and what state is that right in? | It makes eligibility, renewal, and claims legible at the user level. |
Why this model matters
It allows OmegaX to separate:
- plan-level capital and trust policy
- reusable policy-series terms
- member-specific participation state
That separation is important for coverage, protection, sponsor plans, and future capital comparability.
What the current protocol model supports
At the protocol-model layer, the current public surface supports:
- policy-series creation and update flows
- policy-series payment options
- member self-subscribe and operator issue pathways
- policy positions and optional wallet-visible NFT linkage
- premium ledgers and payment rails
- quoted activation, premium truth, and reserve-aware claim handling
Product availability still depends on the published launch status, posted reserve, and staffed review readiness for the specific product.
Why policy series matter
Policy series make it easier to:
- run multiple offerings under one plan
- update or compare offerings over time
- connect claims and pricing to clearer series semantics
- support sponsor-led, open, and more constrained participation modes on the same foundation
Payment-rail reality
Coverage needs more than one payment path.
For that reason, OmegaX supports surfaces that can handle:
- onchain payments
- attested offchain payments
- multiple asset rails over time
- restricted or wrapper-aware paths where needed
Why this page is only one layer
Products and policies are only one layer of the coverage story.
Coverage also depends on:
- claims and settlement
- premium truth
- reserve effects
- interoperability and coding depth for richer products
Plan families inside the same foundation
OmegaX is not limited to a single coverage style.
The same shared health-plan foundation can support:
- simpler protect or acute-event products with clear triggers
- broader coverage plans with richer policy state
- sponsor-led plans with stronger operating requirements
- later AI-assisted plan management around the same rights and reserve structure
That matters because OmegaX is stronger when product breadth comes from one coherent foundation rather than from separate primitives for every new idea.