Oracle and Settlement

Signals v1 uses a signed pull oracle and a two-step settlement process to keep finalization predictable and resilient to failures. The goal is to make settlement both open to participation and clear in its finality: anyone can submit data, but once a tick is finalized it does not change.

Settlement is a protocol event, not a social process. By the time claims open, the system has already committed to a single tick. Positions pay out only against that tick and the half-open payout rule.

Figure: Candidate submission, decision window, and finalization with fallback.

Settlement timeline

Each market has a settlement timestamp $T_\text{set}$ and three global timeline parameters:

• $\Delta_\text{settle}$: sample submission window length
• $\Delta_\text{ops}$: decision window length
• $\Delta_\text{claim}$: claim delay

The protocol enforces:

$$\Delta_\text{claim} = \Delta_\text{settle} + \Delta_\text{ops}$$

The windows around $T_\text{set}$ follow a simple state machine:

• Trading: $t < T_\text{set}$
• SettlementOpen: $T_\text{set} \le t < T_\text{set} + \Delta_\text{settle}$
• PendingOps: $T_\text{set} + \Delta_\text{settle} \le t < T_\text{set} + \Delta_\text{settle} + \Delta_\text{ops}$
• ClaimOpen: $t \ge T_\text{set} + \Delta_\text{claim}$, with settlement finalized

Trading closes at $T_\text{set}$. Claims open only after the claim delay and only after finalization has fixed a settlement tick.

These labels are derived from timestamps and lifecycle flags. They are not a separate oracle product. A transaction either falls in an admissible window and can update state, or it falls outside and reverts.

Signed pull oracle model

Oracle data is signed off-chain and can be submitted on-chain by anyone during the oracle window. The protocol validates the signature, feed ID, and timestamp relative to the settlement time. The closest valid sample becomes the settlement candidate.

This model separates data production from data submission. The oracle provider signs the data; any participant can carry it on-chain. That keeps settlement open without trusting a single relayer.

This is the trust boundary. The chain can validate which signed payload was used and that it satisfied admissibility rules. The chain cannot validate that the external data source was correct. Settlement is deterministic given an admissible payload; payload truth remains external.

The "closest valid sample" rule defines how the market maps a continuous data stream into a single settlement tick at a specific time. It removes ambiguity about which point in the data stream is used for settlement and makes candidate selection deterministic.

That rule also makes the timeline explicit: settlement is anchored to a moment, not a window. Given the signed data and the rule, the candidate is uniquely determined.

Sample validity checks

Submitted samples are accepted only if they satisfy a bounded timing rule around $T_\text{set}$.

Each sample has a signed price timestamp $t$ and a chain time $t_\text{now}$ at submission. Two guards apply:

• Future tolerance: $t \le t_\text{now} + \delta_\text{future}$
• Max sample distance: $|t - T_\text{set}| \le \Delta_\text{max}$ (unless $\Delta_\text{max}=0$)

The protocol also enforces the window boundary: samples are accepted only during SettlementOpen.

These checks are local, mechanical constraints. They do not make an oracle true; they constrain which signed points in the data stream are eligible to serve as a settlement candidate for a specific market day.

Candidate selection

Let the market's settlement time be $T$. Each submitted oracle sample has a timestamp $t$ and a value $x$. Samples are validated against signature rules and a bounded timing rule around $T$.

Among valid samples, the protocol selects the candidate whose timestamp is closest to $T$:

$$t^* = \underset{t}{\arg\min}\; |t - T|$$

On ties, the protocol keeps the more past sample (the smaller timestamp). This tie-breaker makes candidate selection deterministic even when an oracle stream produces two equally distant timestamps around $T$.

The candidate value $x^*$ is then mapped to a settlement tick using the market's tick mapping rule (defined by bounds and tick spacing). The result is a single tick index that becomes the input to claims.

Signed prices are converted into the protocol's settlement value units before tick mapping. The oracle feed has its own decimals; the protocol scales the settlement value into a fixed on-chain unit used across markets.

Tick mapping is a deterministic clamp-and-align rule. Out-of-range values are clamped into the first or last tick of the market domain. Values inside the domain map to one tick bucket under half-open semantics. See Market Design for the grid definition.

Finalization

Candidate submission and settlement finalization are separate steps.

During SettlementOpen, the system collects a single best candidate using the closest-sample rule. After SettlementOpen ends, finalization becomes available and is gated by an authorization layer.

Finalization availability is time-gated by the settlement schedule, not by UI flow. In contracts, primary finalization is admitted as soon as PendingOps begins:

$$t \ge T_\text{set} + \Delta_\text{settle}$$

There is no requirement to wait until the end of the decision window. The window exists to provide an explicit period where the system can either finalize the candidate or explicitly reject it and take the failure branch.

Primary finalization performs three actions atomically:

1. maps the candidate value to a settlement tick using the market's grid mapping
2. marks the market settled with a settlement tick and a finalization timestamp
3. clears the candidate so it cannot be reused across days

Finalization also triggers the market's accounting transition into the daily batch: maker-side PnL is recorded and the payout reserve for open positions is escrowed as part of settlement.

Fallback settlement

The protocol includes an explicit failure branch for oracle issues.

During the decision window, an authorized action can mark settlement as failed. This discards any current candidate. A failed market cannot proceed on the primary path.

Secondary settlement is a separate finalization path for failed markets. It finalizes the market using an explicit settlement value and maps that value to a tick using the same grid mapping rule.

The split between primary and secondary settlement separates routine settlement from exceptional settlement. The exceptional path exists to prevent a market day from stalling indefinitely when the primary oracle path is not acceptable for that day.

In the current release, the observable distinction between primary and secondary finality is the finalization event. The derived market-state helper is primarily a timeline stage label and should not be treated as a complete classification of finality path.

Secondary settlement still uses the same grid mapping rule. The difference is which value is mapped. Primary settlement maps the selected oracle candidate. Secondary settlement maps an explicit value provided to the exceptional path.

Claim gating

Positions become claimable only after two conditions are true:

• settlement has been finalized to a tick
• the claim delay has elapsed since $T_\text{set}$

The claim delay is defined from the settlement timestamp rather than from the finalization block time. This yields a predictable daily schedule even when finalization happens later than the earliest possible moment.

Edge cases

Oracle settlement concentrates many failure modes into explicit outcomes:

• No sample submitted: no candidate exists. The market cannot finalize on the primary path until a candidate exists.
• Many samples submitted: the closest-sample rule collapses them into a single candidate, with a deterministic tie-breaker.
• Out-of-range values: tick mapping clamps into the first or last tick of the market domain.
• Future-dated samples: future tolerance rejects samples too far ahead of chain time at submission.
• Chain congestion: the chain execution environment can delay sample submission, finalization, and claims. The schedule is expressed in timestamps, but the chain still needs to process transactions.

Worked selection sketch

This sketch shows the exact candidate rule and the tie-break behavior.

Let $T_\text{set} = 1{,}700{,}000{,}000$ and let two admissible samples be submitted during SettlementOpen:

• sample A at $t_A = T_\text{set} - 5$
• sample B at $t_B = T_\text{set} + 5$

Both samples are at distance 5 from $T_\text{set}$. The tie-break rule keeps the more past sample, so the candidate becomes sample A.

If a third admissible sample arrives at $t_C = T_\text{set} - 1$, it replaces the candidate because its absolute distance is strictly smaller.

The rule is mechanical: the candidate depends only on the set of admissible samples and the timestamps, not on submitter identity or submission order.

Related sections:

• Market Lifecycle
• Market Design
• Positions and Payouts