Oracle & Resolution

Oracle architecture is the bridge between real-world weather and on-chain settlement. Getting this right is critical — both for accurate settlement and for regulatory compliance.

Design Principle: Separation of Pricing and Settlement

The engine prices the risk. Independent oracles determine whether the trigger was hit.

This separation is non-negotiable for two reasons:

1. Benchmark manipulation risk — under SFA Part 12 Division 2 (Singapore), manipulation of any financial benchmark is a criminal offence. If the engine's own output were used as the settlement reference, Cliff Horizon would be both pricing and settling its own products — creating a conflict of interest and potential regulatory exposure.

2. Client trust — institutional clients require settlement based on independent, verifiable data. Using the engine's own forecast as the settlement trigger would undermine the product's credibility.

Oracle Data Sources

Resolution Workflow

Weather event occurs
    ↓
Oracle data published (NWS, SatSure, etc.)
    ↓
Cliff Horizon RESOLVER service:
  - Fetches oracle data from primary source
  - Cross-checks against secondary source
  - Verifies data integrity and completeness
    ↓
RESOLVER submits on-chain:
  resolvePolicy(policyId, payoutAmount)
    ↓
Smart contract executes:
  - If trigger met → payout released
  - If trigger not met → capital unlocked

Chainlink Integration

For on-chain data delivery, the oracle architecture can integrate with Chainlink — the industry standard for decentralised oracle networks. Chainlink provides:

• Decentralised data feeds — multiple independent node operators verify the data
• Cryptographic proofs — verifiable data provenance
• Existing weather data adapters — Chainlink has existing integrations with weather data providers

The question for Ensuro is whether to use existing Chainlink weather infrastructure or to build a custom oracle adapter. This is part of the integration discussion.

Fallback Hierarchy

Each policy defines a fallback hierarchy for data availability issues:

1. Primary source available — use primary source data
2. Primary source delayed — wait up to defined period (e.g., 48 hours)
3. Primary source unavailable — fall back to secondary source
4. Both sources unavailable — fall back to tertiary source or governance mechanism

For ForecastEx temperature contracts, the NWS Climatological Report has its own documented fallback:

1. Daily Climatological Report maximum temperature
2. If discrepancy with intraday report → delay to allow revision
3. If no revision → use daily report value
4. If no final report → use greater of intraday report or highest METAR observation

Data Provenance Requirements

Ensuro and BMA may have specific requirements for oracle data provenance. Key questions under discussion:

• Does BMA require dual-source verification for settlement data?
• Are there specific data provider certifications required?
• What data retention requirements apply to settlement records?
• How does BMA view satellite-derived data (SatSure) as a settlement source?

RESOLVER Role in Practice

The RESOLVER role is held by Cliff Horizon's oracle service — an automated system that:

1. Monitors observation periods for active policies
2. Fetches settlement data from agreed oracle sources when available
3. Validates data quality and cross-checks against secondary sources
4. Submits resolution transactions on-chain
5. Logs all resolution activity for audit trail

Resolution is automated in the normal case. Manual intervention is only required when data sources disagree or are unavailable — handled according to the fallback hierarchy.