Claims & Settlement
OmegaX supports both reward consequences and coverage consequences, but richer coverage products require an explicit claim model.
That is one of the places where OmegaX stops looking like a simple rewards protocol and starts looking like real plan infrastructure.
Use this page when you need to understand how claims become auditable economic objects rather than hidden support tickets.
The current public protocol surface supports claim cases, evidence references, claim attestations, adjudication, obligations, reserve booking, and settlement paths. Product availability and claim-review staffing are still product-specific boundaries.
Reward versus coverage claims
Reward claims are usually:
- faster
- simpler
- tied to recognized outcome completion
Coverage claims are often:
- more stateful
- more evidence-sensitive
- more connected to reserve and review logic
Both should still reconcile to one shared accounting foundation.
That shared accounting layer is what keeps OmegaX from becoming one system for rewards and a completely separate system for more serious coverage behavior.
What a claim needs to express
A serious claim object may carry:
- intake status
- review state
- approval or denial outcome
- payout consequence
- reserve booking and release
- appeal or recovery context
The point is to make the lifecycle visible. A claim should not disappear into hidden operator workflow once it becomes economically important.
How a claim moves through the system
While products differ, the current reviewed coverage-claim flow in the public protocol surface follows this shape:
| Step | What happens |
|---|---|
| 1 | A member submits a coverage claim. |
| 2 | Evidence and decision-support references are attached to the claim case. |
| 3 | One or more schema-bound oracle attestations can be anchored against the active claim case. |
| 4 | An authorized adjudicator reviews the claim in light of the claim state and attestation path. |
| 5 | If approved, the protocol reserves and settles the related obligation through the supported payout path. |
| 6 | The claim is closed once the case is resolved. |
That is what turns claims into auditable economic objects rather than support tickets.
In the current public surface, day-to-day reviewed claim actions are delegated through approved oracle and adjudicator keys, while governance remains the control layer for broader protocol and pool policy.
For the current Genesis Protect launch wording around evidence review, disputes, and reserve-backed payout posture, use:
Interoperability and coding for richer claims
Not every OmegaX claim needs the deepest healthcare-administration model.
But richer coverage products may eventually depend on external standards such as:
- FHIR for structured evidence exchange
- CPT, HCPCS, ICD, LOINC, and related coding families for claim semantics
Those standards should feed OmegaX through offchain normalization and evidence packaging.
The protocol should then anchor:
- references
- commitments
- adjudication consequences
- reserve and payout effects
That keeps OmegaX interoperable without turning it into a raw medical-record database.
Why premium truth matters
Claims do not stand alone.
Coverage products also depend on explicit premium or contribution truth:
- what was due
- what was paid
- what was attested offchain
- what grace or delinquency state applies
That is what makes claims enforceable instead of interpretive.
Why reserve-aware settlement matters
Settlement should not pay from ambiguous balances.
Claims and payouts need to reconcile against:
- explicit reserve state
- plan risk controls
- free-capital constraints
- policy-valid status transitions
That is how OmegaX stays economically honest as product depth increases.
Why this matters to members and sponsors
Members need a system where claim rights are legible and review does not feel arbitrary.
Sponsors and operators need a system where reserve, payout, and denial behavior can be explained and audited.
That is why claims and settlement are central to the public OmegaX story, not only an implementation detail.