Threat Model

High-level threat model for Signals v1. It is not an exhaustive audit, but a structured view of where risks live and how the protocol mitigates them.

Signals is a range market, so its threat model is not identical to a binary prediction market or a pool-based AMM. The shared curve, the outcome grid, and the daily settlement window introduce specific surfaces. Mitigations in v1 are designed around these surfaces.

Scope

The threat model covers on-chain contracts and state transitions, oracle data submission and settlement flows, and governance-authorized actions.

The model is organized by mechanism surfaces rather than by UI components. A threat is categorized by which invariant surface it targets: pricing coherence, settlement meaning, claimability, or accounting consistency.

Assets and invariants

The protocol has a small number of core assets and invariants that define what "security" means in Signals:

• Payout correctness: a position pays exactly according to the finalized settlement tick and the half-open range rule.
• Finality immutability: once a settlement tick is finalized, it does not change.
• Pricing coherence: CLMSR pricing remains normalized and path independent, and does not permit contradictory prices from trade ordering.
• Accounting consistency: daily updates conserve value under the fee and allocation rules and do not introduce drift through rounding.

Many threats can be described as attempts to violate one of these invariants or to exploit uncertainty where the protocol explicitly relies on off-chain truth (oracle inputs) or authority (governance).

Non-goals

• It does not guarantee oracle truth, only signature validity.
• It does not remove governance trust assumptions.
• It does not assume continuous settlement.

Assumptions

• Governance follows published policy and secures its keys.
• Oracle signatures are generated by authorized providers.
• External data sources remain outside the on-chain trust boundary.
• Chain liveness is sufficient for settlement and claims to complete.

Trading and settlement boundaries are enforced by timestamps and state machines. The assumptions are therefore about external truth and authority rather than about off-chain enforcement.

Adversary capabilities

The model assumes adversaries can observe mempool activity, submit trades near timing boundaries, and attempt to exploit rounding or timing ambiguities. The protocol’s defenses are explicit boundaries and deterministic rules rather than obscurity.

The model also assumes adversaries can:

• submit multiple competing oracle samples during the submission window,
• attempt to force a candidate change by gaming tie cases,
• attempt to delay finalization by contributing to congestion or censorship,
• attempt to create accounting drift by exploiting integer division at unit boundaries.

The model also assumes adversaries can submit valid signed oracle samples if they can obtain them, and can attempt to delay or censor settlement-related transactions under chain congestion. These are liveness and submission-layer risks, not purely contract logic risks.

The model does not assume perfect coordination among adversaries. Many attacks are opportunistic: exploiting a boundary, exploiting a price-impact pattern, or exploiting a delay. Determinism reduces the space where opportunistic behavior can change semantics.

Threat surfaces

Signals v1 has four primary threat surfaces:

• Trading surface: adversarial sequencing, MEV, and state movement between submission and inclusion.
• Settlement surface: oracle sample admissibility, candidate selection, and permissioned finalization.
• Accounting surface: payout reserve escrow, daily batching, and rounding at unit boundaries.
• Authority surface: upgrades, configuration updates, executor allowlists, and pause state.

Many threats do not attempt to break math directly. They attempt to exploit a boundary between surfaces.

Signals v1 tries to turn boundaries into explicit rules:

• trades are admitted only inside the trading window,
• oracle samples are admissible only inside SettlementOpen,
• a settlement tick is written only by an explicit finalization transition,
• claims are payable only after finality and claimOpen,
• vault batches process only when every market for the day is resolved.

A large fraction of threat analysis reduces to checking whether a boundary can be crossed in an ambiguous way. The mechanism response is to either revert or keep the day non-final until a valid transition occurs.

Primary risks

• Oracle manipulation: incorrect or missing settlement information.
• Governance compromise: unauthorized changes.
• Smart contract bugs: loss of funds or incorrect state transitions.
• Liveness failures: delayed settlement or claims.
• Boundary gaming: attempts to exploit the timing boundary between trading and settlement.
• Outcome ambiguity: disputes about which tick a noisy data point should map to at settlement time.
• Resolution mismatch: tick spacing that is finer than the data quality can create perceived unfairness even when settlement is correct.

Mitigations

Signals v1 relies on signed oracle data, explicit settlement windows and finality, and public event logs for attribution and traceability. Conservative rounding and on-chain transparency reduce ambiguity.

The outcome grid and half-open intervals remove boundary ambiguity at payout time. The “closest valid sample” rule removes ambiguity about which data point counts. The daily state machine makes timing boundaries explicit.

The threat model is a map of trust boundaries. It separates what is enforced by on-chain rules (tick mapping, finality gating, deterministic claims) from what is assumed (oracle truth, governance behavior, and chain liveness).

Execution risk is concentrated in depth, fees, and timing boundaries. Settlement risk is concentrated in oracle validity and the settlement state machine. Governance risk is concentrated in upgrades and configuration changes.

Mitigations are expressed as concrete on-chain rules:

• sample admissibility constraints around $T_\text{set}$ (future tolerance and max distance)
• deterministic closest-sample candidate selection with a tie-breaker rule
• explicit finalization that records a settlement tick and finalization timestamp
• claim gating as a time rule plus finalization requirement
• payout reserve escrow at settlement so claims draw from reserved funds
• deterministic rounding direction for debits and credits

The design goal is legibility: when something changes, it changes on-chain, and the change is attributable. That does not remove trust assumptions, but it does make them visible.

Concrete scenarios

Threats are easiest to reason about through scenarios tied to explicit protocol rules.

Scenario A: Mempool boundary gaming near the close

An adversary can submit trades close to $T_\text{set}$ and attempt to reorder them relative to other trades. The mechanism does not prevent reordering. The mechanism makes execution well-defined for any inclusion order:

• base pricing is path-independent given the final state,
• realized execution depends on inclusion order because the state update is chosen by inclusion.

The risk is execution quality, not settlement ambiguity.

Scenario B: Future-dated oracle sample injection

An adversary can attempt to submit a sample with an embedded timestamp ahead of the current block time. The future tolerance gate rejects such samples. The failure mode is explicit: the submission reverts and no candidate update occurs.

Scenario C: Denial of settlement by missing data

An adversary cannot force a false settlement tick without oracle control, but an adversary can contribute to delayed finality by withholding usable signed data or by attacking liveness. The mechanism response is explicit delay:

• the day remains non-final,
• trading remains closed,
• claims remain closed.

The fallback route exists to ensure the state machine can still resolve when the primary oracle path does not produce a candidate.

Scenario D: Rounding extraction attempt

If rounding direction were inconsistent, repeated buy and sell loops could exploit integer division to extract value. Signals bounds this surface with two deterministic rules:

• costs round up,
• proceeds round down.

Residual dust from fee split and batch conversion is handled deterministically so it cannot become a discretionary pool.

Threat to invariant map

The table below maps common threat categories to the invariant surfaces they target and to the mechanism responses that bound damage.

Threat category	Target surface	Mechanism response
Oracle manipulation or missing data	Settlement correctness	Signature checks, time gating, explicit non-final states, fallback settlement path
Boundary gaming at the close	Trading and settlement boundary	Explicit lifecycle windows, trading closed during oracle window and decision window
Curve exploitation	Pricing coherence	Path-independent cost structure, normalization and monotonicity invariants
Rounding exploitation	Accounting consistency	Deterministic rounding rules and conserved accounting boundary
Governance compromise	Authority surface	On-chain traceability of changes, regime boundaries, explicit upgrade and configuration history
Chain liveness failure	Settlement and claims liveness	Claims and finality delayed rather than executed off-chain