Protocol Snapshot

Signals v1 turns continuous outcomes into a tradable on-chain market by combining three pieces that are usually separated across products: a tick grid, a shared CLMSR curve, and explicit daily settlement. The protocol surface is small but mechanically dense: trading is a state transition, and settlement is a state lock.

This page is a single-pass map of the day loop and the objects that make the loop well-defined.

Snapshot

Signals v1 repeats the same lifecycle for every market day:

1. Define the market: choose a domain, a tick spacing, and depth.
2. Seed the prior: apply the market's seed factors until the market is tradable.
3. Trade ranges: positions are half-open intervals on the tick grid and all ranges hit the same curve.
4. Submit oracle samples: signed samples are admissible only inside the submission window.
5. Finalize settlement: a single tick is written on-chain as finality.
6. Claim: payouts are released from escrow after the claim gate opens.

The loop is stable across markets. The market parameters change, but the order of admitted transitions does not.

Mechanism objects

Signals v1 stays legible because there are only a few shared objects, and each one has a precise on-chain meaning.

Outcome grid and tick mapping

Every market defines an outcome domain and a tick spacing. Settlement maps a real-world value to a single tick by clamping and spacing alignment. The grid is the settlement contract: it defines what it means for an outcome to be "inside" or "outside" a position.

If a market's domain is $[L, U)$ and its spacing is $s$, then the grid contains $n = (U-L)/s$ bins and the tick index for an observed value $x$ is:

$$\text{tickIndex}(x) = \mathrm{clamp}\!\left(\left\lfloor\frac{x - L}{s}\right\rfloor, 0, n-1\right)$$

The inverse interpretation is equally important. A tick index $i$ represents a half-open bucket:

$$x \in [L + i s,\ L + (i+1)s)$$

This is the content of settlement meaning. A day does not settle to an arbitrary real number. It settles to one of these buckets and then claims use bucket membership under half-open semantics.

On-chain, the settlement value is represented as a fixed-point integer and then mapped to an aligned tick by clamping to the market bounds and aligning to tickSpacing. That mapping is deterministic and is part of the protocol's behavioral surface.

Positions use half-open intervals $[\text{lowerTick}, \text{upperTick})$. This convention makes boundary behavior explicit and avoids double counting at adjacent edges.

Payout is binary over the interval at the finalized settlement tick $\tau$:

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

Shared curve and state updates

Signals v1 does not maintain separate pools per range. A single pricing state $q$ prices every tick and every contiguous range. A trade is a state update on $q$. Fee-free cashflow is the cost function difference:

$$\Delta C = C(q_{\text{after}}) - C(q_{\text{before}})$$

The same state $q$ prices narrow and wide ranges, which is the mechanism meaning of shared liquidity.

For a contiguous range $R$, the range price mass at state $q$ is a sum of tick prices:

$$p(R; q) = \sum_{i \in R} p_i(q)$$

A buy of quantity $x$ on $R$ is a structured state update:

$$q' = q + x \mathbf{1}_R$$

and the fee-free base cost is:

$$\text{baseCost}(x; q, R) = C(q + x \mathbf{1}_R) - C(q)$$

The same structure applies to sells with a negative sign. This makes range trading a direct state transition rather than a peer-to-peer match.

Depth, slippage, and effective price

Depth $\alpha$ is the scale parameter of the curve. It determines how quickly range prices move as $q$ changes under a trade. Slippage is the mechanical cost of moving the shared curve; it is not a fee.

Execution has two layers:

• base pricing from the curve (state movement), and
• fees applied after base pricing as a policy overlay.

The effective execution amount is the value that enters realized PnL. Buys add fees on top of base cost and sells subtract fees from base proceeds.

For small trades, there is a useful approximation that separates "quote times size" from the leading slippage term. Let $p$ be the starting range price mass and $x$ the trade size. Then:

$$\text{baseCost}(x; q, R) \approx x p + \frac{x^2}{2\alpha}p(1-p)$$

The quadratic term is the slippage term and makes the role of depth explicit.

Execution also has explicit bounds:

• buys supply maxCost and revert if baseCost + fee > maxCost
• sells supply minProceeds and revert if baseProceeds - fee < minProceeds

The protocol rounds at the unit boundary. Internally, math uses WAD fixed point and transfers use ctUSD units. Debits round up and credits round down. This rounding direction is an explicit part of execution behavior.

Settlement and claims

Settlement does not emerge from matching or from averaging. It is an explicit finalization transaction that records one settlement tick $\tau$ on the market's grid. Claims are deterministic functions of $(\tau,\text{range},\text{quantity})$.

Oracle submission is time-gated. Signed oracle samples are admissible only inside the submission window $[T_\text{set}, T_\text{set}+\Delta_\text{settle})$. The oracle module maintains one candidate per market and updates it using the closest-to-$T_\text{set}$ rule (absolute distance, tie-break toward the past).

Claims are also time-gated. Let $T_\text{set}$ be the settlement timestamp and let $\Delta_\text{settle}$ and $\Delta_\text{ops}$ be the submission and decision window lengths. The claim delay is enforced as:

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

The claim gate time is $T_\text{set} + \Delta_\text{claim}$, but claims still require settlement finality to have been written on-chain.

At finalization, the protocol escrows a payout reserve for the market day. Claims draw from that escrow. The reserve is decremented as claims execute, and the implementation reverts if a claim would exceed the remaining reserve. This ties claimability to the settlement boundary rather than to future maker value.

A worked day sketch

Consider a BTC market with an outcome grid and tick spacing chosen at market creation. The market is seeded from its prior factors until market.isSeeded flips true.

During the trading window, the shared curve prices every contiguous range on the grid. A narrow range (for example $[60{,}000, 62{,}000)$) concentrates the state update on fewer ticks, which makes execution more sensitive to depth. A larger quantity pushes the curve farther along the same potential surface.

One way to see the geometry is to separate two sources of execution movement:

• a narrower range concentrates the update on fewer ticks, increasing the rate at which range price mass changes as the position grows
• a larger quantity moves farther along the same curve, increasing average price paid relative to the starting quote

At $T_\text{set}$, signed oracle samples are admissible during the submission window. The oracle module maintains one candidate, replacing it only when a new sample is closer to $T_\text{set}$ under the closest-sample rule. Settlement finality later records a single tick $\tau$ on-chain.

After the claim gate opens, the position pays its fixed quantity if $\tau$ lands inside the half-open interval and pays zero otherwise. Claims burn the position token and transfer ctUSD from the payout escrow reserved at settlement.

Event vocabulary

The day loop can be followed directly through events and view helpers.

Market lifecycle:

• MarketCreated records the grid, timestamps, and depth.
• MarketSeedingProgress and MarketSeeded record seeding completion.
• SettlementPriceSubmitted and SettlementCandidateUpdated record admissible oracle samples and candidate selection behavior.
• MarketSettled and MarketSettledSecondary record finality.

Trading and claims:

• PositionOpened, PositionIncreased, PositionDecreased, PositionClosed record position changes and base amounts.
• TradeFeeCharged records the fee overlay applied on top of base pricing.
• PositionClaimed records deterministic payout release after the claim gate.

Related sections:

• Market Design
• CLMSR Pricing Curve
• Liquidity Depth and Slippage
• Market Lifecycle