Skip to main content

Plan Objects & State

OmegaX becomes much easier to understand when you stop treating it as one large program and read it as a small set of durable plan objects.

Together, these objects describe what a plan is, who participates, what can be claimed, how reserves behave, and what capital is exposed to.

Health plan​

The health plan is the root object.

It defines:

  • who can participate
  • what events matter
  • how outcomes are recognized
  • what assets are used
  • what can be paid
  • what capital and claims rules apply

Product and series layer​

A single plan can support multiple products or series under the same broader economic foundation.

This layer is where OmegaX expresses:

  • reusable product templates
  • coverage or protection terms
  • pricing and payment options
  • comparability metadata across plan offerings

Member position​

The member position is the protocol view of a participant inside a plan.

It brings together:

  • eligibility status
  • subject commitment or plan linkage
  • policy or product participation
  • claim and cycle relevance
  • delegated rights where permitted

Liability and reserve state​

OmegaX needs explicit accounting for:

  • what has already been promised
  • what is reserved
  • what is pending review
  • what remains free for redemption or new obligations

This is the foundation for serious capital participation.

Claim case​

OmegaX supports both reward and coverage consequences, but richer coverage flows require an explicit claim object.

A claim case can carry:

  • intake state
  • review state
  • approval or denial outcome
  • payout consequence
  • reserve release or persistence
  • appeal or recovery context

Compliance and credential surfaces​

Not every plan needs regulated participation, but OmegaX needs room for it.

This layer covers:

  • eligibility credentials
  • action-level policy constraints
  • transfer and rail restrictions
  • wrapper-aware participation modes

Asset rails​

Plans and capital classes should not be locked forever to one payment or token path.

OmegaX is designed to support:

  • SOL and SPL paths today
  • broader rail flexibility over time
  • restricted or wrapper-aware rails where required

Capital class​

Capital-provider exposure should live in an explicit capital object, not in member-facing policy artifacts.

A capital class is the place where OmegaX can express:

  • class-specific exposure
  • priority and restriction rules
  • reference NAV
  • redemption windows or queues
  • future market distribution

Why the object model matters​

These objects let OmegaX support many product modes without losing accounting clarity.

They also make the protocol easier for sponsors, capital providers, and builders to understand because each major economic question has an explicit home in the system instead of disappearing into operator workflow.

Download PDF