Architecture
Event production, sponsor operations, and compliance workflow stay around the protocol. Shared rights, liabilities, reserves, and settlement live onchain.
OmegaX is built in layers so the protocol can be economically strict without pretending every healthcare workflow belongs onchain.
That architecture is what lets OmegaX stay both market-facing and healthcare-realistic.
One foundation, three layers
1. Event production and oracle layer
This layer turns messy real-world health and coverage inputs into protocol-usable events.
It includes:
- OmegaX Health as the first event-production app and oracle surface
- future compatible oracle providers
- evidence normalization, attestation packaging, and privacy filtering
- AI-assisted interpretation where policy allows it
This is where private data is interpreted and structured events are produced.
2. Sponsor and operator layer
This is where institutions and operators configure plans and run products.
Examples include:
- sponsor consoles such as Business
- operator workflows for plan setup and reporting
- policy and product administration
- claims and compliance operations where local process is still required
This layer is responsible for usability, reporting, and distribution.
3. Shared health-plan foundation on Solana
The onchain OmegaX protocol is the shared economic layer.
It is responsible for:
| Capability | What it means |
|---|---|
| Health plans | The root plan object for capital, terms, oracle policy, and operating boundaries |
| Membership and policy rights | Who can participate, what they can hold, and what remains active |
| Schemas and outcomes | The event language the system can recognize and settle |
| Claims and settlement | Reward and coverage consequences recorded against explicit state |
| Capital and redemptions | Capital-class participation, reserves, and redemption constraints |
| Governance and safety | Scoped controls, pauses, and protected invariants |
One settlement foundation, multiple access models
OmegaX should be able to support more than one route into the market without fragmenting its accounting truth.
That includes:
- fully DeFi-native plans that use the shared foundation directly
- sponsor-led plans with tighter operational policy
- credential-aware or wrapper-constrained participation when legal structure or distribution requires it
- higher-trust coverage products with more evidence, review, and reserve discipline
The rule is not that every product must look the same.
The rule is that they should settle against the same underlying foundation when they share the same rights, liabilities, reserves, and payout logic.
The boundary rule
OmegaX does not try to put every healthcare workflow onchain.
The protocol is best used for:
- rights that many parties need to trust
- liabilities and reserves that must stay explicit
- capital state that must remain auditable
- settlement consequences that should be durable and composable
OmegaX should keep these around the protocol instead:
- raw health data
- raw claims payloads
- local human workflow
- institution-specific compliance processing
- wallet and market UX
Why this architecture matters
This split gives OmegaX the best of both worlds:
- a public settlement and capital layer that many parties can trust
- flexible offchain systems for privacy, AI, reporting, and local workflow
That is how OmegaX can become real infrastructure instead of merely wrapping an operator workflow in blockchain language.