Skip to main content

Parametric insurance

Parametric insurance pays out automatically when a measurable event crosses a threshold — no claims adjuster, no paperwork, no months of waiting. It's a near-perfect match for on-chain settlement: the event is verifiable, the payout is formulaic, the timing matters.

What's missing is the verification step — someone has to confirm "yes, the flight was delayed", "yes, the exchange got hacked", "yes, the rainfall in region X exceeded the trigger". That's what OMY provides.

Use cases​

Flight delay insurance​

User buys a policy: "Pay $200 if flight LH123 on 2026-03-15 departs more than 3 hours late." The policy contract escrows $200 in USDT. On the flight date, the contract calls RequestResolution with the question. An asserter verifies via flight data API (FlightRadar24, FlightAware) and proposes the answer + bond. After liveness, the answer is accepted and the payout fires — or the user's premium is forfeit.

Smart-contract exploit cover​

A DeFi user buys cover against a specific protocol getting exploited within a year. The cover pool escrows the payout. Trigger: "Did protocol X experience a verified exploit resulting in loss of user funds > $1M between dates A and B?" Resolver: OMY. If yes, payout fires; if no, premium goes to the pool.

Weather / agricultural​

A farmer buys index insurance against drought: "Did rainfall in district X between months Y and Z fall below 30mm according to source W?" OMY verifies the answer. Insurer pays out automatically.

The contract shape​

simplified parametric policy
struct PolicyState {
 holder: address
 triggerQuestion: cell
 payoutAmount: coins
 deadline: uint32 // when the event window closes
 status: uint8 // OPEN | AWAITING | PAID | EXPIRED
 boundAssertion: address?
}

match (msg) {
 OracleResult => {
 var st = Storage.load();

 // Anti-spoof + dedupe
 assert (in.senderAddress == st.boundAssertion!) throw Err.NotOurOracle;
 assert (st.status == STATUS_AWAITING) throw Err.AlreadyHandled;

 if (msg.answer) {
 // Trigger fired — pay out
 st.status = STATUS_PAID;
 sendUsdt(st.jettonWallet!, st.holder, st.payoutAmount);
 } else {
 // No trigger — premium stays in the pool
 st.status = STATUS_EXPIRED;
 }
 st.save();
 }
 // ...
}

Design considerations​

The data source is the trust boundary​

The hardest part of parametric insurance is defining the data source. The question must reference a specific, verifiable source. Vague references ("if the flight is delayed") get disputed forever; specific references ("according to FlightRadar24's actual arrival time field, ≥ 3h vs scheduled") have a single source of truth.

Some practical patterns:

  • Use authoritative APIs: flight data → FlightRadar24, weather → NOAA, smart-contract exploits → official postmortem from project + 3rd-party audit firm
  • Reference exact field names: "the actual_arrival_time field at flightradar24.com/data/flights/lh123/... minus the scheduled_arrival_time"
  • Specify timezone, threshold, and tolerance explicitly

Pool design​

A single-policy contract is fine for proofs of concept, but real insurance needs a pool model:

  • Premiums from many policies → one pool
  • Payouts from policies that trigger → drawn from pool
  • Pool surplus → to LP / underwriter
  • Pool deficit → policies pay out pro-rata until exhausted (or LP gets margin-called)

OMY doesn't dictate the pool model — that's your business logic. It just provides the truth signal for whether each policy's trigger fired.

Liveness sizing​

For insurance, liveness should be longer than for prediction markets because:

  1. The payout amount per policy is fixed — there's no continuous trading pressure for fast settlement
  2. The dispute incentive is asymmetric — a single insurer might lose $200,000 on a wrongly-decided claim while a watcher bot only earns the dispute bond
  3. Off-chain verification (flight data, weather data, exploit confirmation) may take hours

Suggested: 24-72 hours for most parametric insurance. Some events (exploits, where postmortems take days) need a week or more.

Resolver choice​

For Phase 1, the committee is appropriate for most parametric insurance — the signers can quickly verify "did this flight depart on time" against authoritative sources. As $OMY matures and the DVM accumulates stake, high-stakes insurance can route to DVM for distributed verification.

Risks​

import {DocFeatures, DocFeature} from '@site/src/components/docs/DocFeatures';

What if FlightRadar24 is down at the resolution moment? Your question template must specify a fallback (alternative source, default to NO). Did the airline classify it as "delay" or "cancellation"? Define your terms precisely. Template guide. If too many policies trigger simultaneously (e.g., volcanic eruption grounds a region), the pool may be inadequate. Reinsurance / dynamic pricing helps. A malicious actor disputes every claim. They lose money on bonds, but delay payouts. Conservative liveness + dispute-watcher bots mitigate.