Product Modes & Lifecycle
Use this page to see how different products share one lifecycle instead of becoming separate protocols.
OmegaX Protocol supports multiple product modes on one shared health-plan foundation.
That matters because the protocol is not meant for one narrow product wedge. It is meant to support a family of health-plan expressions without rewriting the economic base each time.
Product modes
| Mode | Main use | Shared foundation piece |
|---|---|---|
| Permissionless rewards | Lower-friction outcome programs | Member position, outcome finality, payout state |
| Sponsor-led plans | Employer, provider, or operator programs | Health plan, funding lines, reporting truth |
| Coverage and protection | Premiums, claims, reserves, and payouts | Policy series, claim cases, obligations |
| AI-supported operations | Pricing, triage, review, and orchestration support where authorized | Protocol-anchored final state |
| Regulated participation | Credentialed or wrapper-constrained access | Same plan economics with bounded controls |
| Capital-market participation | LP exposure, classes, redemption queues | Pools, classes, allocations, reserve ledgers |
1. Permissionless rewards
- open or token-gated participation
- verified outcomes trigger rewards
- lower-friction, higher-speed plan design
2. Sponsor-led plans
- employer, provider, or operator-managed participation
- stronger reporting and control needs
- the same settlement foundation with tighter plan policy
3. Coverage and protection products
- reusable products or series under a shared plan
- premium and claim state
- explicit reserve and payout consequences
4. AI-supported operations
- AI helps with pricing, review, triage, or orchestration where authorized
- final enforceable state still lands in protocol logic
5. Regulated participation modes
- compliance-bound or wrapper-constrained participation on the same foundation
- restricted rails where needed
- same underlying plan economics with additional controls
6. Capital-market participation
- explicit capital classes
- reserve-aware redemption logic
- wallet-visible exposure and secondary distribution where supported
Canonical lifecycle
Most OmegaX products follow the same broad flow.
1. Plan creation
A sponsor, operator, or builder creates a health plan with:
- eligibility policy
- oracle trust policy
- payout and claim rules
- asset and capital settings
2. Capital formation
The plan is funded by sponsor capital, treasury capital, outside capital, or some mix of the three.
3. Enrollment and access
Members currently join through open, token_gate, or invite_only membership modes.
Invite-only plans use an invite_permit proof path at enrollment time. Token-gated plans can use fungible_snapshot, nft_anchor, or stake_anchor gate kinds behind the same plan-level token-gate model.
Plans can also apply compliance bindings and rail restrictions around those flows when the product needs tighter participation controls.
4. Product or series selection
The plan may offer one or more reward, coverage, or protection paths under the same foundation.
5. Event production
Health or coverage-relevant signals are observed, normalized, and turned into protocol-usable events.
6. Finality
Oracle policy, review, or challenge mechanics determine when an event becomes valid for settlement.
7. Liability update
The protocol books the relevant consequence:
- claimable reward
- claim review state
- reserve impact
- payout obligation
8. Settlement
Funds move only through explicit protocol instructions and policy checks.
9. Reporting and renewal
Sponsors, operators, and capital providers evaluate outcomes, reserves, and economics for continuation or new issuance.
10. Capital consequences
Payouts, claims, and reserve usage feed back into capital performance, free-capital availability, and subsequent plan design.
Why the shared lifecycle matters
This common lifecycle is what lets OmegaX support many product forms without splitting into one protocol for rewards, another for coverage, and another for capital.
It gives sponsors a cleaner operating model, gives builders a more stable object model, and gives capital a more legible economic surface to evaluate.