Program Spec (Solana)

This is the canonical technical spec for the on-chain OmegaX protocol.

Implementation Status

• v0.1 is implemented in the current OmegaX on-chain program.
• v0.1 uses SOL-lamport pool liquidity for deterministic end-to-end settlement.
• SPL-token vaults, tranche mechanics, and advanced oracle/dispute modules are planned extensions.

Design Goals

1. Permissionless pool creation and usage.
2. Oracle-pluggable outcome verification.
3. Deterministic and auditable payout settlement.
4. Privacy-preserving identity linkage (no raw personal health data on-chain).
5. Open composability for third-party frontends, backends, and SDKs.

Non-Goals

1. No medical diagnosis logic on-chain.
2. No storage of raw telemetry (wearable streams, biometrics, PHI).
3. No requirement that OmegaX Health is the only oracle.

Permissionless Model

• Anyone can create a pool if they satisfy protocol rent/fee requirements.
• Any oracle can register and stake.
• Any frontend can integrate if it follows instruction contracts.
• Protocol governance controls global parameters, not pool-specific business policy.

Program Modules

1. core_pool: pool lifecycle, funding, budgets, windows.
2. membership: enrollment, eligibility proofs, membership records.
3. oracle_registry: oracle registration, stake, status, slashing hooks.
4. attestation: attestation replay protection and verification checkpoints.
5. claims: claim submission, validation, settlement state machine.
6. payout: vault debits and wallet transfers.
7. governance_hooks: protocol-level limits and emergency controls.

Core Accounts

Account	Purpose	Owner/Authority
ProtocolConfig	Global parameters and safety limits	Governance authority
Pool	Pool metadata, policies, limits, status	Pool authority
MembershipRecord	User enrollment and status per pool	Program
OracleRegistryEntry	Oracle identity, key, status, stake config	Oracle + program
OracleProfile	Structured oracle profile (org type, URLs, capabilities, claim state)	Oracle admin + oracle key + program
PoolOracleApproval	Pool-specific oracle allowlist entry	Pool authority + program
CoverageProduct	Reusable coverage template per pool (terms hash, schedule, pricing defaults)	Pool authority + program
CoveragePolicy	Member-specific policy position for a pool (one per member per pool)	Program
CoveragePolicyPositionNft	Optional linkage record for policy NFT metadata/mint	Program
CycleOutcomeState	Per-member, per-cycle attestation aggregate	Program
AttestationReplay	Replay-protection record keyed by replay hash	Program
ClaimRecord	Claim lifecycle and final settlement outcome	Program

Pool Config Model

A pool stores:

• pool_id
• organization_ref (opaque string/id, optional for permissionless pools)
• authority_pubkey
• payout_lamports_per_pass (v0.1)
• membership_policy (open, token-gated, invite-permit, or composition)
• oracle_policy (single signer, allowlist, threshold quorum)
• payout_policy (caps, windows, per-outcome/per-member constraints)
• start_slot_or_ts, end_slot_or_ts
• status (draft | active | paused | exhausted | closed)
• metadata_uri

Membership Policy Model

Membership is policy-driven per pool:

1. open: any wallet may enroll.
2. token_gate: wallet must hold minimum amount of configured SPL mint (example: $OMEGAX).
3. invite_permit: wallet must submit a valid signed permit from issuer authority.
4. composed: any_of or all_of over rules above.

This supports:

• Employer/insurer private cohorts.
• Community pools.
• OmegaX consumer pools for $OMEGAX holders.

Instruction Set (v0.1 implemented + planned)

Instruction	Signers	Effect
initialize_protocol	protocol admin	Initializes global config
create_pool	pool authority	Creates Pool and PDA links
fund_pool	funder	Funds pool account with lamports
set_pool_status	pool authority	Pauses/resumes/ closes pool
register_oracle	oracle key	Creates oracle registry entry
register_oracle_v2	admin wallet	Creates registry entry (if missing) + structured on-chain profile for an oracle pubkey
claim_oracle_v2	oracle key	Claims and activates the registered oracle pubkey
update_oracle_profile_v2	oracle key or profile admin	Updates structured oracle profile fields and capability hashes
set_pool_oracle	pool authority	Approves/disables oracle for a specific pool
enroll_member	member wallet (+ optional issuer)	Creates or updates MembershipRecord after policy checks
register_coverage_product_v2	pool authority	Creates reusable pool-scoped coverage product template
update_coverage_product_v2	pool authority	Updates product template metadata/terms/schedule
subscribe_coverage_product_v2	member wallet	Member subscribes to product and creates member policy position
issue_coverage_policy_from_product_v2	pool authority	Operator issues/renews member policy from selected product
revoke_member	pool authority	Marks membership revoked
submit_outcome_attestation	approved oracle key	Stores replay-safe attestation + updates cycle aggregate
submit_claim	claimant wallet	Settles payout directly from pool liquidity when checks pass

Planned in next versions:

• stake_oracle, unstake_oracle, slash_oracle
• SPL token vault payout path
• threshold quorum attestation verification
• dispute/challenge window and arbitration hooks

Claims and Payout State Machine

v0.1 state progression:

1. Oracle submits one or more replay-safe attestations for {member, pool, cycle}.
2. CycleOutcomeState accumulates attestation_count and pass_count.
3. Claimant submits claim transaction signed by wallet.
4. Program transfers payout and marks cycle as claimed.

Deterministic rejection reasons include:

• membership_inactive
• policy_mismatch
• attestation_invalid
• attestation_replay
• budget_exhausted
• window_expired
• claim_duplicate

Oracle and Attestation Contract

The on-chain program validates:

1. Attestation signer identity against pool oracle policy.
2. Attestation time window and nonce/domain fields.
3. Uniqueness of attestation replay key.
4. Outcome/event compatibility with pool payout policy.

The program does not require OmegaX-only formats; it requires canonical payload fields and signature validity.

Oracle Key Separation (Admin vs Oracle Signer)

register_oracle_v2 supports operational separation between:

• Admin wallet: registers the oracle identity/profile and manages organization metadata.
• Oracle signing key: cryptographic key that must call claim_oracle_v2 to activate itself.

This two-step flow prevents silent impersonation when registration and signer wallets differ, while preserving enterprise onboarding workflows where an operator provisions the profile before the oracle signer team completes claim/activation.

Coverage Primitives (v2)

Coverage is intentionally pool-scoped and modeled as:

1. Health Plan (Pool): capital + oracle policy + membership policy.
2. Coverage Product (CoverageProduct): reusable template under a pool (terms hash, duration, premium cadence/grace, premium amount defaults).
3. Coverage Policy Position (CoveragePolicy): member policy account created from a selected product.
4. Policy NFT Link (CoveragePolicyPositionNft): optional metadata/mint linkage.

Design constraints:

• A single pool can host multiple product templates (shared liquidity context).
• A member has one active policy position per pool (policy PDA keyed by pool+member).
• Member path and operator path are both supported:
  • subscribe_coverage_product_v2 (member self-subscribe)
  • issue_coverage_policy_from_product_v2 (operator issue/renew)

Security Invariants

1. Pool funds can only move through protocol instructions.
2. No payout without active membership + valid attestation + policy pass.
3. Every payout must map to exactly one settled claim id.
4. Replay keys are globally unique per attestation domain.
5. Claim idempotency key is stable and cannot settle twice.
6. Circuit breakers cap payout velocity per epoch.

Identity and Invite Bridging

• On-chain identity is wallet + opaque subject commitment.
• Invite flow remains off-chain in issuer/partner backends.
• Enrollment permit signatures bridge invite eligibility to on-chain membership without exposing email/PII on-chain.

See: protocol/identity-membership.

Oracle Separation of Duties

• Outcome attestations are signed by oracle/verifier keys.
• Claim transactions are signed by claimants (or their authorized custodial operator).
• Protocol verifies both trust boundaries separately.

Implementation Phasing

1. v1: pool, membership, oracle registry, attestation refs, claim settlement.
2. v1.1: threshold oracle quorums and challenge window.
3. v1.2: tranche/share extensions and redemption windows.
4. v2: coverage-style policy modules and secondary market primitives.

Compliance Boundary

Protocol remains neutral infrastructure. Regulatory wrappers are implemented by deployers/frontends as optional modules and policy constraints.