Products, Policies & Plan Families
OmegaX coverage products run on the layered health-plan model in OmegaX Protocol.
The goal is to make products, policy rights, premiums, claims, reserves, and settlement legible parts of one public economic system.
Use this page for the generic coverage model before reading the bounded Genesis Protect launch pages.
The current protocol model supports coverage objects, premium records, reserve-aware claims, and policy-series semantics. Specific OmegaX product availability still depends on posted reserve, published terms, and staffed review.
Genesis Protect launch pack
For the current Genesis Protect Acute product example, use the dedicated pages:
- 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 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-subscription and approved issuance pathways
- policy positions and optional wallet-visible NFT linkage
- premium ledgers and payment rails
- quoted activation, premium records, and reserve-aware claim handling
Product availability still depends on the published launch status, posted reserve, and staffed review 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
- supported payment and attested contribution paths for published products
- 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 records
- 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
- AI-assisted plan management around the same rights and reserve structure where supported
That matters because OmegaX is stronger when product breadth comes from one coherent foundation rather than separate primitives for every offering.