How GADUIN Verifies Flight Delay Outcomes | Oracle Design
GADUIN settles flight delay event contracts in USDT through a deterministic multi-source oracle — verifiable outcomes, no claims, no discretionary review.
Every event contract settles on a single question: what actually happened? For a flight delay contract, that translates into a precise data problem — which sources recorded the event, how reliably, and what happens when signals conflict. Subjective or opaque resolution erodes market integrity; deterministic, auditable resolution builds it.
GADUIN’s settlement oracle is built around that data problem. This article breaks down the flight data architecture behind outcome verification, explains how the oracle converts tracking data into a settlement signal, and compares that approach to resolution mechanisms used by adjacent platforms.
Why Outcome Verification Matters in Event Contracts
The Risk of Subjective Resolution
The fundamental challenge in event contract markets is keeping resolution objective. Polymarket routes contested outcomes through UMA’s Optimistic Oracle — a dispute mechanism where UMA token holders vote on challenged proposals within a multi-day resolution window. The model is appropriate for open-ended questions (election results, regulatory decisions) where no objective data standard exists. For a flight landing — a timestamped physical event — a voting period that outlasts the contract is a structural mismatch, not an edge case.
Kalshi, operating under CFTC oversight, anchors settlement to named source agencies specified in each market’s contract rulebook. That approach is credible, but settlement completeness depends on when those named agencies publish their data, which can lag the flight event by hours or days in the case of aggregate airline statistics.
GADUIN’s Approach: Deterministic, Data-Driven Settlement
GADUIN’s settlement oracle is fully deterministic and automated. The outcome state — On Time, Delayed, or Cancelled — is resolved algorithmically the moment the oracle receives consistent data from independent flight-tracking sources. No dispute queue, no committee review, no bonding period.
This matters to the two primary audiences trading on GADUIN: retail participants managing exposure to route-specific delay risk, and institutional desks using event contracts to hedge operational costs. Both groups need settlement finality with a predictable timeline, not a governance process that extends uncertainty after the flight has already landed. For a broader overview of how the underlying contracts work, see How Flight Delay Event Contracts Work.
What Flight Data Sources Does GADUIN Use?
GADUIN’s oracle aggregates data from multiple independent aviation tracking providers. The categories below describe the types of providers involved in flight delay outcome verification and the role each plays in the oracle’s data architecture.
Real-Time Aircraft Tracking
Providers such as FlightAware aggregate ADS-B transponder signals, FAA and EUROCONTROL data feeds, and proprietary multi-lateration networks to produce gate-to-gate flight tracking. For outcome verification, the relevant outputs are actual departure time, airborne status, and actual gate-arrival time at the destination. This data is publicly verifiable on consumer tracking platforms and forms the primary real-time signal in an automated settlement oracle.
Global Schedule and Status Coverage
Enterprise flight status platforms — Cirium’s FlightStats data being a reference example across the industry — normalise airline-reported status, airport FIDS (flight information display systems), and live tracking feeds into a global dataset. This category of provider serves as a cross-reference layer: if a real-time tracker reports a gate arrival, an enterprise status platform independently confirms it through a separate data ingestion path.
Schedule Authority and Timing Reference
Delay is defined relative to schedule. OAG (Official Airline Guide) is the authoritative source for scheduled departure and arrival times used across the aviation industry, from carriers to airport slot coordinators. The oracle locks the scheduled arrival time from the schedule authority at contract activation — meaning any subsequent airline timetable adjustments cannot retroactively shift the delay calculation’s baseline. A reschedule after activation does not move the reference point.
Why Multi-Source Redundancy Reduces Oracle Risk
No single provider has universal coverage across all airports, carriers, and regions. Feed latency, regional data gaps, and outages are operational realities in global aviation data. GADUIN’s oracle requires multi-source agreement before settling a contract — not a single feed.
This architecture also closes a data-layer manipulation vector. An entity that could theoretically interfere with one provider’s feed cannot shift the settlement outcome if two or more independent sources report a divergent result. The oracle resolves on consensus.
How the Oracle Turns Flight Data into a Settlement Signal
The settlement process follows a defined four-step sequence from contract open to USDT execution.
Step 1 — Reference Frame Locked at Contract Open
When a GADUIN flight delay contract activates, the oracle records the scheduled departure time, scheduled arrival time, and destination airport code from the designated schedule authority. These form the fixed reference frame. Post-activation schedule changes by the airline do not alter this frame — the delay calculation runs against the original scheduled time.
The data source committed at activation is identified in the contract specification and is publicly accessible.
Step 2 — Multi-Source Query at Expected Landing
At the scheduled arrival time (plus a propagation buffer for final data feed latency), the oracle queries all configured flight-tracking sources simultaneously and compares reported actual gate-arrival times across sources.
If sources agree within a defined tolerance: settlement proceeds immediately.
If minor discrepancies exist: a reconciliation pass is triggered.
If a source is temporarily unavailable: the oracle falls back to the remaining sources, provided a required quorum is met.
Step 3 — Deterministic Delay Calculation
Delay is calculated as: actual gate arrival time − scheduled arrival time (reference). The result is compared to the delay threshold specified in the contract’s terms at activation. The threshold is encoded into the contract at open and does not change at settlement.
If the calculated delay equals or exceeds the contract’s threshold, the outcome resolves as Delayed. If the flight lands within threshold, the outcome is On Time. A flight that does not operate resolves as Cancelled.
This is arithmetic on verified timestamps — no discretionary weighting, no contextual adjustment.
Step 4 — USDT Settlement Execution
Once the oracle publishes its outcome, USDT settlement executes automatically. Participants holding positions on the settled outcome close at the contract’s final settlement price. Position values are reflected on-chain without manual intervention.
The full oracle-to-settlement sequence is designed to complete within a defined window after the flight’s scheduled landing. For the full settlement mechanics, see How GADUIN Settles Flight Delay Contracts in USDT.
Manipulation Resistance: Can Flight Data Be Gamed?
Manipulation resistance is not theoretical when a contract settles on real-world data. Two layers of attack surface matter: the data source layer and the oracle computation layer.
Independence of Data Sources
Aviation tracking and schedule data providers serve airline operations, enterprise analytics, and travel infrastructure — markets with no relationship to event contract settlement. They produce their data products for clients who need operational accuracy, not financial derivatives outcomes. This absence of settlement incentive is a key independence property: there is no rational motivation for a flight data provider to alter timestamps or status codes to influence a position on a derivatives exchange.
On-Chain Audit Trail of Oracle Calls
Each oracle query and its data inputs are recorded on-chain at settlement time, producing an immutable, timestamped audit trail. Any market participant can verify which sources were queried, what data each returned, and precisely how the settlement algorithm converted those inputs into an outcome state. Opacity at settlement time is eliminated by design.
What Happens When Sources Conflict?
If sources report gate-arrival times that diverge beyond the reconciliation tolerance, the oracle applies a defined conflict-resolution protocol:
- Majority signal (two or more sources in agreement) is adopted.
- If no majority exists, a source-precedence rule defined in the contract’s terms applies — for example, the schedule authority’s airline-reported data may take precedence over derived position-tracking estimates for timing calculations.
- All conflict events are logged on-chain with full source data.
The resolution protocol is deterministic throughout. No human discretion enters the path.
Defining “Delayed”: Edge Cases and Settlement Rules
Settlement precision requires unambiguous definitions. Three edge cases determine how the oracle handles non-standard flight events.
Delay Thresholds
Each GADUIN contract specifies its delay threshold in the contract terms at activation. Contracts are structured by tier — a shorter-threshold contract resolves Delayed on smaller delays, while a longer-threshold contract requires a more significant delay to resolve. The exact threshold for a given contract is visible in its specification before any position is opened.
Cancelled vs. Diverted Flights
A cancelled flight — one that does not operate — has no actual gate-arrival time. Cancellations resolve as Cancelled, a discrete outcome distinct from Delayed, with its own settlement price determined by the two-sided market. Diversions (flights landing at an airport other than the scheduled destination) are classified separately: a diversion is not treated as a delay under GADUIN’s settlement rules, and the contract terms specify how diversion events are classified.
Missed Connections
GADUIN’s flight delay contracts settle on the leg-level outcome of the specified flight, without reference to any downstream connecting itinerary. Missed connections are a passenger-level consequence of delay, not the primary event being tracked by the oracle.
GADUIN vs. Other Settlement Approaches
| Dimension | GADUIN | Polymarket (UMA) | Kalshi | Etherisc FlightDelay |
|---|---|---|---|---|
| Resolution method | Deterministic algorithm | Tokenized vote on proposals | Named source agencies | Chainlink parametric oracle |
| Settlement timeline | Automated, near-real-time | Multi-day dispute window | Tied to named agency cycle | Automated via smart contract |
| Dispute mechanism | None — consensus oracle | Bond/slash + UMA token vote | CFTC rulebook | None |
| Instrument type | Event contract | Prediction market | Event contract (CFTC-reg.) | Parametric insurance |
| Settlement currency | USDT | USDC | USD | DAI/crypto |
| Claims & premiums | No — positions settle on outcome | No | No — contract settlement | Yes — insurance claims & premiums |
Polymarket’s dispute model is well-suited for outcomes without an objective data standard. For flight delay verification — a verifiable timestamped event — the dispute window is a structural overhead that GADUIN’s deterministic oracle eliminates.
Kalshi’s named-agency model is CFTC-compliant and credible but carries settlement latency tied to publication cycles that can trail the actual flight event.
Etherisc’s FlightDelay product uses Chainlink oracles to feed flight status data into smart contracts that automate parametric insurance claims. The oracle architecture shares conceptual overlap, but the financial instrument is categorically different: Etherisc is an insurance product with premiums and claims; GADUIN is an event contract exchange where participants open and close market positions. See Etherisc FlightDelay vs. GADUIN and Parametric Insurance vs. Prediction Markets for a deeper comparison.
Verifiable Outcomes, Not Claims
Flight delay is a physical, timestamped event — not a judgment call. That characteristic makes it well-suited for deterministic oracle settlement: multi-source data aggregation, a fixed reference frame locked at contract activation, and an algorithmic outcome calculation that runs the same way regardless of market conditions.
GADUIN’s oracle is designed to produce settlement finality that both retail traders and institutional hedgers can rely on. The outcome is either On Time, Delayed, or Cancelled, derived from the same aviation data infrastructure the industry uses to run its operations — and recorded on-chain where any participant can verify the inputs.
This content is for informational purposes only and does not constitute financial or investment advice. Trading event contracts involves the risk of loss. U.S. persons are excluded from participation. See gaduin.com/user-agreement and gaduin.com/terms for full terms.