Signals v1 Docs

Signals v1 sits at the intersection of prediction markets and mechanism design. It prices continuous outcomes on a tick grid with a shared CLMSR curve, settles markets once per day, and exposes pricing and settlement as public on-chain state transitions.

Status (as of February 6, 2026): the protocol is under audit and LP access is private in v1. Treat the system as unaudited and do your own research (DYOR) before use.

Signals is built around a small set of invariants that keep the market coherent: one global curve prices all ranges, depth controls price impact, and settlement finalizes to a single tick. Those choices make the system both tradable and coherent: a market day is a self-contained unit of pricing, settlement, and claims, and the pricing state is public.

Signals is easiest to model in terms of three objects: the grid, the curve state, and the finalized settlement tick. Most behavior in v1 is a consequence of how these three objects interact over a market day.

At a low level, trading is a state transition and settlement is a state lock. The trade module updates a market-local CLMSR state; the lifecycle module later freezes one tick as the settlement outcome and escrows the payout reserve used by claims. That separation is what makes the mechanism legible: trading is continuous, but finality is explicit.

Figure: The protocol sits between participant roles and two daily primitives: the market cycle and maker accounting.

The mechanism in three statements

1) Continuous outcomes become a grid. A continuous value is mapped to a single tick. The mapping is deterministic, so settlement is locked into a single on-chain meaning instead of debated off-chain.

2) One curve prices all ranges. Every trade moves the same CLMSR curve. This pools liquidity across the grid and makes pricing coherent across narrow and wide ranges alike.

3) Finality happens once per day. Settlement is explicit and time-gated. Once a tick is finalized, claims become deterministic.

These three statements also define the "mechanism surface" of v1:

• the grid defines payout meaning
• the curve defines trade cost as a state transition
• the daily lifecycle defines when settlement meaning is locked

The three statements can also be written as three invariants that the implementation maintains:

• tick mapping is deterministic and aligned to tick spacing
• fee-free cashflow is a cost function difference $\Delta C$
• settlement is single-tick and immutable once finalized

In symbols, a range trade is a state update $q \to q'$ and the fee-free cashflow is:

$$\Delta C = C(q') - C(q)$$

Fees are an overlay applied to $\Delta C$ to produce the executed cost or proceeds in ctUSD. Settlement maps an oracle observation into a single tick $\tau$ on the grid, and payouts are deterministic functions of $(\tau,\text{range},\text{size})$.

A market day, end to end

A market opens with an outcome range and tick spacing. Traders take range positions that encode “inside vs outside” outcomes. The shared curve updates as trades happen. At settlement time, signed oracle data produces a single settlement tick. After finality and the claim delay, positions are claimed for payout. That daily rhythm is the accounting unit of the protocol.

The order of actions is time-gated on-chain. Trading is admitted only inside the market's trading window, oracle samples are admitted only inside the submission window, and claims are admitted only after both finality and the claim delay. This makes "what is valid now" a property of timestamps, not a property of user interface flow.

The daily boundary is also the accounting boundary. Maker-side PnL and fee allocation are realized once per day at the batch step. This keeps the ledger discrete and aligns settlement, claims, and maker accounting to the same day key.

Trading surface

Traders choose a range and a size. The curve determines the base cost. Depth controls how much the price moves as the position grows. Slippage is central rather than incidental. Fees are applied after base pricing to create the effective price that determines real PnL.

Range width and size are the explicit geometry in Signals. Narrow ranges encode more precision but concentrate the state update on fewer ticks. Larger size pushes the curve further along the same potential surface. Both effects show up as a predictable change in executed average price relative to the starting quote.

Trading entrypoints take explicit slippage bounds. Buys take maxCost and sells take minProceeds. Those parameters are not pricing inputs; they are execution constraints that cause the transaction to revert if the effective execution price is worse than the bound. This makes execution behavior explicit in transaction calldata rather than implicit in UI settings.

Units are also explicit. Internally, the mechanism uses WAD fixed point for math and then rounds to ctUSD units for transfer. Debits round up and credits round down. The rounding direction is part of the behavioral surface of the protocol, because it defines the conservative boundary between math and accounting.

Start Here

The start section frames the core ideas and the daily rhythm of the protocol. It is the fastest path to understanding what makes Signals a continuous market with explicit finality.

• What Is Signals v1 — the high-level thesis and what makes the mechanism distinct.
• Protocol Snapshot — the full flow on one page.
• Signals in One Day — the daily cycle from trading to finality.
• Roles in Signals v1 — traders, oracle reporters, and governance at a high level.
• Concept Map — how the ideas connect to the whitepaper.
• Contract Addresses — on-chain anchors for reference addresses.

Core Mechanics

Core mechanics cover how continuous outcomes become tradable, how pricing works, and how finality is enforced. This is the conceptual core of Signals.

• Market Design — the outcome grid and tick mapping that make settlement deterministic.
• CLMSR Pricing Curve — the shared curve and path-independent pricing.
• Liquidity Depth and Slippage — depth as liquidity, slippage as the cost of moving the curve.
• Positions and Payouts — how ranges encode payout logic, including the half-open interval rule.
• Fees and Effective Price — fee overlay and how it affects effective price.
• Market Lifecycle — the state machine that turns a trading day into finality.
• Oracle and Settlement — signed data, candidate selection, and finalization.

Trading

Trading in Signals is interaction with a curve rather than a peer-to-peer match. The guides below describe how to choose ranges, size positions, and interpret prices in a system where depth and slippage are central.

• Trader Journey — the flow from market selection to settlement and claims.
• Trader FAQ and Scenarios — common scenarios and the intuition behind costs and payouts.

Trust & Safety

Signals is transparent but not fully trustless. The trust & safety material lays out the trust assumptions, governance role, failure modes, and limits of the system.

• Trust & Safety Overview — guarantees, assumptions, and public observability.
• Governance and Trust Model — how upgrades and routine operations are authorized.
• Governance Journey — governance at a high level.
• Protocol Transparency — on-chain state and event model.
• Failure Modes and Fallbacks — how the system handles oracle failure and finality issues.
• Threat Model — risks and mitigations.
• Invariant Summary — core correctness constraints in pricing and settlement.
• Known Limitations — deliberate tradeoffs.
• Audits — current audit status.

Reference

Reference material for deeper dives and formal properties.

• Architecture
• Units and Rounding
• Glossary
• CLMSR Invariants

Whitepaper

The whitepaper is the formal specification, proofs, and full mechanism design. See Whitepaper.

Changelog

Protocol changes over time. See Changelog.