Schemas, Outcomes & Oracle Consensus

This page explains how OmegaX defines verifiable health outcomes, stores them securely, and uses multi-Oracle consensus to trigger on-chain rewards and coverage settlements.

What Is a Schema?

A Schema is a JSON document that lists the health outcomes a Health Plan (Pool) or Coverage Policy can incentivize. Each outcome is a specific, binary health achievement — for example:

Outcome ID	Label	Condition
`bp_systolic_control`	Blood Pressure Managed	Systolic BP ≤ 130 mmHg (7-day avg)
`a1c_control`	Diabetes HbA1c Managed	HbA1c ≤ 6.5%
`wl_steps_on_track`	Sustained Weight Loss Activity	≥ 7,000 daily steps (7-day avg)
`sleep_duration_at_least_7h`	Better Sleep & Recovery	≥ 420 min sleep/night (7-day avg)

Schemas follow the omegax.schema spec and are stored on IPFS for immutability. The on-chain SchemaSummary account stores:

A metadataUri — the IPFS link to the JSON file.
A schemaHashHex — a SHA-256 hash of the JSON contents, ensuring the file cannot be silently altered.

Why Use Hashes Instead of Plain Text?

Each outcome in the schema includes a valueHashHex — a deterministic cryptographic fingerprint. The smart contract uses this hash (not the human-readable label) for three reasons:

Fixed-size storage: Solana accounts use fixed byte layouts. A SHA-256 hash is always exactly 32 bytes, regardless of how long the outcome name is.
Future-proofing: Simple outcomes like "Blood Pressure Managed" may evolve into complex conditions like "bp_reduced_by_10%_from_baseline_over_28d". The hash keeps on-chain cost constant.
Privacy optionality: Not all schemas are public. Enterprise clients may define private outcome sets. The hash allows the contract to function without revealing the human-readable meaning on the public ledger.

For standard, public health outcomes, the hash is primarily a convention for consistency across the protocol.

How Oracle Consensus Works

OmegaX does not put raw health data (e.g., "BP was 118 mmHg") on-chain. Instead, it uses a hash-based Oracle quorum pattern.

The Flow

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Oracle 1   │     │  Oracle 2   │     │  Oracle 3   │
│ (Apple Health)│   │ (OmegaX Agent)│   │ (Doctor Portal)│
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
       │                   │                   │
       │  Off-chain:       │  Off-chain:       │  Off-chain:
       │  "Is BP ≤ 130?"   │  "Is BP ≤ 130?"   │  "Is BP ≤ 130?"
       │  → YES            │  → YES            │  → YES
       │                   │                   │
       ▼                   ▼                   ▼
  Submit hash:        Submit hash:        Submit hash:
  3b2cb202...         3b2cb202...         3b2cb202...
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                    ┌──────▼──────┐
                    │ Smart Contract │
                    │ Quorum: 2/3   │
                    │ 3 hashes match │
                    │ → PAYOUT ✓    │
                    └───────────────┘

Step-by-Step

Schema published: The outcome bp_systolic_control with hash 3b2cb202... is published to IPFS and registered on-chain.
Pool configured: A Health Plan (Pool) creates a RuleSummary that references this schema and sets an Oracle Policy with a quorum (e.g., 2-of-3).
Oracles evaluate off-chain: Each Oracle independently checks the user's private health data against the outcome condition (BP ≤ 130?). They never share the raw data.
Oracles submit on-chain: If the condition is met, each Oracle submits the pre-agreed hash (3b2cb202...) to the smart contract.
Quorum reached: Once the required number of matching hashes is received, the smart contract automatically triggers the payout.

Why Not Put the Logic On-Chain?

Evaluating if BP < 120 then pay directly in the smart contract would require:

Broadcasting private health data to a public blockchain — violating HIPAA/GDPR.
The blockchain to read wearable devices — which is physically impossible without an Oracle.
Expensive on-chain computation — health logic often involves multi-day averaging, AI heuristics, and data quality checks.

The hash-based pattern gives you the trustlessness of DeFi without leaking health data or paying excessive computation costs.

Oracle Policy Configuration

Each Health Plan (Pool) configures an Oracle Policy (PoolOraclePolicySummary) with:

Field	Description
`quorumM`	Minimum number of Oracle votes required to approve an outcome
`quorumN`	Total number of Oracles in the validator set
`requireVerifiedSchema`	Whether the schema must be governance-verified
`allowDelegateClaim`	Whether a third party can claim rewards on behalf of the member

Example configurations:

DeFi Yield Farm: 1-of-1 quorum (single automated Oracle for speed).
Corporate Wellness: 2-of-3 quorum (wearable device + AI agent + manual review).
Health Insurance: 3-of-5 quorum (multiple independent clinical data sources for maximum trust).

Schema Storage

Storage Method	Use Case	Trade-off
IPFS / Arweave	Public schemas, DeFi pools, DAOs	Immutable, decentralized, tamper-proof
Centralized HTTPS	Enterprise HR, private wellness programs	Fast to update, but requires trust in the host

The on-chain schemaHashHex ensures integrity regardless of where the JSON is hosted. Even if the file is moved or the host goes down, the smart contract continues to function using the cryptographic hashes alone.

What Is a Schema?​

Why Use Hashes Instead of Plain Text?​

How Oracle Consensus Works​

The Flow​

Step-by-Step​

Why Not Put the Logic On-Chain?​

Oracle Policy Configuration​

Schema Storage​