Failure Modes and Fallbacks

Signals v1 is a daily-settled market. That design concentrates failure handling around one question: what happens when settlement data is missing, late, or ambiguous around the daily close.

This page pins down the failure modes as concrete state-machine outcomes. The protocol either:

• refuses an invalid transition by reverting, or
• delays finality and keeps claims closed until a valid finalization occurs.

There is no "soft final" outcome. A market day is either finalized to one tick or it is not finalized.

Timeline and where failures can occur

Each market day is anchored at a settlement timestamp $T_\text{set}$ and three windows:

$$\text{settleEnd} = T_\text{set} + \Delta_\text{settle}$$ $$\text{opsEnd} = T_\text{set} + \Delta_\text{settle} + \Delta_\text{ops}$$ $$\text{claimOpen} = T_\text{set} + \Delta_\text{claim},\quad \Delta_\text{claim} = \Delta_\text{settle} + \Delta_\text{ops}$$

The lifecycle stages correspond to these windows:

• Trading: $t < T_\text{set}$
• SettlementOpen: $T_\text{set} \le t < \text{settleEnd}$
• PendingOps: $\text{settleEnd} \le t < \text{opsEnd}$
• Finalized: after a settlement transaction writes one tick

Failures are mostly concentrated in SettlementOpen and PendingOps. After a market day is finalized, the remaining failure surface is liveness and contract correctness rather than oracle ambiguity.

Oracle submission failure

Oracle settlement uses a signed pull model. A signed sample can be carried on-chain by any submitter. The protocol enforces signature validity and admissible timing constraints, but it does not guarantee that a valid sample arrives during the submission window.

SettlementOpen is the only time when samples are admissible. Submission is permissionless inside that window and rejected outside it:

$$T_\text{set} \le t < T_\text{set} + \Delta_\text{settle}$$

Each submitted sample has a timestamp embedded in the signed payload. Two admissibility constraints are enforced:

• future tolerance $\delta_{\text{future}}$ rejects samples dated too far ahead of the current block timestamp
• max distance $\Delta_{\max}$ rejects samples too far from $T_\text{set}$ in absolute time distance

Let $t_s$ be the submitted sample timestamp. The distance rule is:

$$|t_s - T_\text{set}| \le \Delta_{\max}$$

If a submission fails signature validation or fails admissibility constraints, the transaction reverts and no oracle candidate is updated.

The primary failure cases are:

• No valid sample is submitted before $\text{settleEnd}$.
• Submitted samples are invalid and are rejected by signature or timing checks.
• Samples exist, but none satisfy the admissible distance constraints around $T_\text{set}$.

In these cases, the oracle candidate remains missing. The primary settlement finalization transition requires a candidate. Without it, the finalization call reverts and the market remains non-final.

The concrete consequence is delay. Trading is already closed. Claims remain closed. The day stays unresolved until either a valid candidate exists or the market is explicitly marked as failed.

Candidate selection failures are deterministic

When multiple admissible samples are submitted, the mechanism selects one candidate by a deterministic rule:

• minimize $|t_s - T_\text{set}|$,
• on equal distance, select the more past sample, which is the smaller timestamp.

This rule is applied incrementally as samples arrive. A sample that is not strictly closer than the current candidate is ignored. A sample that is equally close but lies on the future side of $T_\text{set}$ is also ignored if a past candidate exists at the same distance.

Candidate selection can therefore fail only in the admissibility sense. It does not fail by disagreement. If two parties submit the same admissible set of samples, the same candidate is selected.

Oracle divergence and the failure mark

Signals v1 has an explicit failure flag that can be set during PendingOps. This is a state transition, not an off-chain convention. When the market is marked failed:

• any existing primary oracle candidate is discarded, and
• the day is routed to the secondary settlement finalization path.

The secondary path is not "arbitrary settlement." It is a single settlement value supplied by the permissioned finalizer and then converted into a tick by the same tick mapping and spacing alignment rule used in the primary path.

Mark-failed timing rules are strict:

• It is allowed only after PendingOps starts, at $\text{settleEnd}$.
• It is allowed during PendingOps.
• After $\text{opsEnd}$, it is allowed only if no oracle candidate exists. If a candidate exists after $\text{opsEnd}$, the expected resolution is primary finalization, not failure marking.

This rule prevents the system from being stuck in an unresolved limbo. If the oracle never produced an admissible candidate, the market can be routed to the secondary path. If the oracle did produce an admissible candidate, the permissioned primary finalization is available.

The divergence case is the one place where failure marking is allowed even when a candidate exists. Marking failed discards that candidate and forces the day to finalize through the secondary path. This is an authority surface and should be treated as such in the trust model.

Derived stage is not finality

Signals exposes derived lifecycle views that are computed from timestamps. Derived state is useful for UI and indexing, but it is not the same as the on-chain finality bit.

A derived "finalized" stage can be reached simply because time has passed beyond the windows. That does not imply the market has actually been finalized. Actual finality is the explicit on-chain state transition that sets the settled flag and writes the settlement tick.

This distinction matters most under oracle failure. A day can be "past the window" but still unresolved until a finalization transaction is mined.

Fallback settlement is still a single-tick finality

Both the primary and secondary finalization paths write the same three objects into state:

• a settlement value, expressed in the fixed settlement unit,
• a settlement tick derived from that value,
• a settlement-finalized timestamp that records when the transaction was mined.

Once written, the settlement tick is immutable. Claims are defined only in terms of that tick and the half-open position rule. The claim gate is unchanged by the path that produced the tick. Claims remain closed until both:

• the market is finalized, and
• $t \ge \text{claimOpen}$.

Finality also triggers accounting. At finalization, the protocol calculates the day PnL and gross fees for maker accounting, escrows a payout reserve for open positions, and records that day input to the daily batch.

This is why non-final days are not partially claimable. The payout reserve is created at finalization.

Pricing and execution stress

The trading surface can fail in ordinary, explicit ways:

• Trading outside the trading window is rejected.
• Trades can revert when max-cost or min-proceeds bounds are not satisfied under state movement.
• Payment transfers can revert on insufficient balance or allowance.

These are normal transaction reverts. They do not create ambiguous settlement state and they do not create partial claims.

Market listing is also a failure surface. Market creation can revert if the safety envelope is not satisfied under the current maker-side configuration. That failure is visible as a revert and does not create a partially defined market.

Batch readiness coupling

Maker-side accounting is keyed by day and processed in a daily batch. A batch is admissible only when every market assigned to that day has been resolved on the primary or secondary path. If at least one market day is unresolved, batch processing reverts.

This coupling is intentional. It prevents maker accounting from assuming that a market "should have settled." Settlement is an explicit state transition, so batch readiness is expressed as a function of explicit finality.

Chain liveness and delayed finality

All settlement and claim actions are on-chain state transitions. Congestion, halts, or censorship can delay those transitions even when the timestamps would otherwise allow them.

A delayed settlement transaction yields a simple state: the market day is not finalized yet, so claims remain closed. Once the finalization transaction is mined, the finalized tick and claim gate become deterministically defined by the recorded state.

Code risk and audit status

Signals v1 is under audit. Until public audit reports are available, treat the protocol as unaudited and do your own research.

Even with correct intent and strong formal reasoning, contract bugs are a risk. The relevant public question is whether failures surface as explicit reverts and explicit non-final states, rather than as silent ambiguous outcomes.

Related sections:

• Oracle and Settlement
• Trust & Safety Overview
• Audits