Values & Design Rules
OmegaX is not only a technical system. It is a set of choices about what should become shared public infrastructure and what should stay private, local, or operational.
Core values
Permissionless by default
The protocol should stay open even when some plans, capital classes, or wrappers are permissioned.
Permissioned participation should appear as a constrained mode on top of the shared system, not as a separate private primitive.
Open and composable
OmegaX should remain:
- open source
- externally integratable
- legible to outside builders
- compatible with wallets, analytics systems, sponsor consoles, and future market venues
The public promise is not only that OmegaX is usable today. It is that outside builders can understand it, integrate it, and trust that it is becoming more legible over time.
Privacy preserving
The protocol should not require raw health records, private documents, or raw identity payloads onchain.
The chain should primarily hold:
- commitments
- permissions
- references
- rights
- liabilities
- settlement consequences
Capital truth before narrative
The protocol must be able to answer:
- what is funded
- what is reserved
- what is owed
- what is claimable
- what is still free capital
If those answers are vague, the market surface is not ready.
No artificial onchain maximalism
Not every workflow belongs onchain.
OmegaX puts shared financial truth onchain and keeps private, local, or high-frequency process offchain where that design is better.
Design rules
Put shared economic truth onchain
Prefer onchain state when an item:
- affects rights or money
- must be trusted by many counterparties
- benefits from atomic settlement
- should be auditable and composable
Keep sensitive or operational process around the protocol
Prefer offchain or hybrid design when an item:
- contains sensitive data
- changes frequently
- is mostly human workflow
- is jurisdiction-specific
- does not need public composability
Keep policy rights and capital rights separate
Member coverage or reward rights should not be confused with capital-provider exposure.
That separation is essential for honest accounting, clean product design, and future market structure.
One shared health-plan foundation
If two products use the same capital, liabilities, rights, and settlement logic, they should extend the same foundation instead of inventing parallel primitives.
One foundation, many access models
OmegaX should stay open enough for DeFi-native products to use the shared settlement foundation directly.
When legal, credential, or rail constraints are necessary, they should appear as wrapper, policy, or access layers around that same foundation rather than replacing it with a separate private primitive.
That rule matters because OmegaX should not fork into one protocol for open participation and another for institutional distribution. It should be one economic machine with multiple operating modes.
Let AI support the system, not replace it
AI can help with event production, pricing, claims triage, and operations.
The final enforceable state transition should still land in explicit protocol logic.
Practical tests
Every major design decision should survive these questions:
- Does this improve shared economic truth?
- Does this preserve privacy boundaries?
- Does this keep the system open to outside builders?
- Does this keep capital and policy rights economically honest?
- Does this make OmegaX more like real market infrastructure and less like workflow theater?
If the answer to those questions is weak, the design is probably still too app-specific, too opaque, or too dependent on operator interpretation.