Signals in One Day

Signals v1 runs markets as daily units anchored by a settlement timestamp $T_\text{set}$. Trading happens inside an explicit trading window, settlement happens on an explicit schedule around $T_\text{set}$, and maker-side accounting is realized in a daily batch keyed by the same day boundary.

The day unit is not a reporting convention layered on top of continuous pricing. It is encoded in timestamps and enforced by reverts. The lifecycle defines when trades are admitted, when oracle samples are admissible for candidate selection, when finality can be written, and when claims can execute.

Reading Signals as a daily mechanism is useful because it aligns the three protocol primitives that otherwise get conflated:

• trading is continuous state update during the open window,
• settlement is a time-gated lock into a single tick, and
• accounting is a discrete checkpoint after settlement.

Those three primitives all happen "on-chain" in the only meaningful sense that matters for analysis: they are recorded as state transitions, they are time gated, and they are deterministic given the inputs and the pre-state.

Figure: The daily sequence from trading to settlement to claims and batching.

Morning: a market opens

Each market opens with a defined outcome range and tick spacing. The grid fixes what "precision" means for the day: settlement will map to one tick index, and payouts will be computed from tick membership in half-open ranges.

Pricing is continuous during the trading window. CLMSR prices all ticks and all contiguous ranges on a shared curve, so traders express views by moving a state, not by waiting for peer-to-peer matches. As positions change, the curve state moves smoothly, and the tick price vector updates as the gradient of the cost function.

Before a market is tradable, its prior is applied in chunks by seeding. The market becomes tradable when its seeding cursor reaches the bin count and market.isSeeded flips true. Trading entrypoints enforce seeding as a hard precondition.

Seeding matters because it is the on-chain moment when a market becomes well-formed. The system moves from "uninitialized state" to "a normalized curve state that can be priced and traded." Once seeded, the only way the state changes is through trades that pay the CLMSR cost function.

The opening configuration also couples resolution to economics. A tighter grid gives finer settlement granularity, but it increases the number of ticks $n$ and therefore changes the loss scale and admissibility constraints that exist at market creation. Even when a market is admitted, finer grids tend to make narrow ranges behave more sharply because positions concentrate on fewer bins.

The mechanism-level objects for the day are already fixed at open:

• the grid bounds and tick spacing,
• the half-open interval semantics for positions,
• the shared pricing curve state and its depth scale,
• and the timing windows that define when trading closes.

Those objects determine what a trade means and what a claim will mean after finality. The day’s trading is just a sequence of state transitions on top of this fixed grammar.

Settlement window: the outcome is fixed

At settlement time, signed oracle samples can be submitted by anyone during the submission window. The closest valid sample becomes the settlement candidate. The protocol then confirms or rejects that candidate during the decision window, with a fallback path available if the primary candidate fails. Finality is explicit: once a tick is finalized, it does not change.

The time windows are explicit. Let $\Delta_\text{settle}$ be the submission window length and $\Delta_\text{ops}$ the decision window length. SettlementOpen is:

$$t \in [T_\text{set}, T_\text{set} + \Delta_\text{settle})$$

and the decision window begins at $T_\text{set} + \Delta_\text{settle}$.

Candidate selection is deterministic. Samples are admitted only if they satisfy signature and timing constraints. Among admissible samples, the candidate is the one that is closest to $T_\text{set}$ under absolute timestamp distance, with a tie-break toward the past.

This is the point where the protocol stops being about "what traders believe" and starts being about "what the day settles to." The curve state can no longer be changed by trades. Settlement meaning is pinned to a single tick, and the on- chain record becomes a lock.

Finality is an on-chain state transition. A market day is either finalized or not finalized. This removes ambiguous intermediate states where payouts depend on off-chain interpretation.

Claims: payouts become available

Once settlement is finalized and the claim delay passes, positions can be claimed for payout based on the finalized settlement tick. This delay is the bridge between finality and payout, and it gives the system a clean moment when outcomes are fixed and claims become valid.

Claims are deterministic: the payout depends only on the finalized tick and the position’s range. At this point the market’s narrative becomes a simple binary statement: inside the range or outside it.

In the simplest form, the claim rule can be stated as:

$$\text{Payout} = \begin{cases} x, & \tau \in [\text{lowerTick}, \text{upperTick}) \\ 0, & \text{otherwise} \end{cases}$$

This rule does not depend on trade history. It depends only on the finalized tick and the position definition.

Claims draw from an escrowed payout reserve recorded at settlement finalization. This matters for interpretation: claims are not "promises" that depend on a future counterparty. They are deterministic transfers out of a reserve that was locked as part of finality. The claim gate is time-based, but claims still require the finalization transaction to have been mined.

Batch processing status is not part of claim eligibility. Claimability is tied to market-level finality and time gates, not to maker-side accounting steps.

End of day: the batch is processed

Trading results and fees are collapsed into a daily result. The protocol applies a single batch update so the day closes with one accounting checkpoint.

This batch update prevents “in and out” timing games around the close. The day closes once, and the accounting closes with it.

A daily batch makes settlement and fee accounting explicit. It turns the day into a self-contained unit of pricing, settlement, and payout, with one well-defined point where maker-side results and fee allocation are realized.

The batch boundary is also where maker-side accounting is realized. Maker capital underwrites depth during the day. The realized maker-side result is applied once per day after settlement. This keeps maker exposure aligned to the daily market cycle rather than to an intraday stream.

Batch processing is also gated. A batch can only be processed once every market assigned to that batch day has been resolved (primary or secondary settlement). When processed, the protocol applies the fee waterfall, updates maker NAV and share price, and processes aggregate deposit and withdrawal totals at the batch price.

LP access is private in v1, but the accounting object is public: maker-side NAV, the share price, and batch events are part of the protocol state transition history. The daily boundary is the key: it is the moment when intraday trading noise becomes a single, attributable accounting update.

A simple timeline example

• 09:00 Market opens and trading begins.
• 16:00 Oracle window opens; signed samples are submitted.
• 16:30 Decision window confirms the settlement candidate.
• 17:00 Claim delay elapses; claims become valid.

The specific times vary per market, but the ordering is fixed by the state machine.

Market parameters and tick spacing are fixed at open. Finality records the settlement tick, and claim events occur only after the delay.

Trades placed before the oracle window are valid; trades after the window opens are not. That boundary is the split between price discovery and settlement.

Boundary cases

Daily cadence also defines how the protocol behaves under stress:

• If oracle submissions are missing or invalid, finality is delayed and claims remain closed. The market does not finalize early.
• If the chain is congested, finality and claims are delayed because the state transition cannot execute.
• If a market configuration is inadmissible under the safety envelope, market creation reverts and the market is not listed. Trading is not gated by exposure caps in the current release, but trades can still revert for execution bounds such as max-cost and min-proceeds constraints.

Whitepaper sections:

• Market-Cycle Batch
• Oracle and Settlement

Related sections:

• Market Lifecycle
• Oracle and Settlement