Concept Map

Signals v1 can be modeled as a small dependency graph. Each layer fixes a piece of meaning, and later layers assume earlier meaning is already pinned down.

The dependency chain is:

1. Grid: settlement meaning
2. Curve: pricing meaning
3. Execution: depth and fee overlays on top of base pricing
4. Finality: a day resolves to one tick and positions become claimable

Everything else in v1 is either a consequence of this chain or an explicit trust surface around it.

Shared objects and notation

Most pages reuse the same objects and the same notation:

• Market grid parameters: bounds $[L, U)$, spacing $s$, tick count $n$
• Pricing state $q$ and tick prices $p_i(q)$
• Depth $\alpha$ as the scale of price impact
• Fee policy as an overlay on base cost
• Settlement timeline: $T_\text{set}$, $\Delta_\text{settle}$, $\Delta_\text{ops}$, $\Delta_\text{claim}$
• Settlement tick $\tau$ and the half-open payout rule

The mechanism can be summarized as "grid + curve + daily tick." The grid turns a real-world value into an index. The curve turns trades into a deterministic state transition. The daily lifecycle turns a market day into a finalized tick and a claim window.

For reference, the same symbols appear in the core equations:

$$\text{tick}(x) = \mathrm{clamp}\!\left(\left\lfloor\frac{x - L}{s}\right\rfloor, 0, n-1\right)$$ $$p(R; q) = \sum_{i \in R} p_i(q)$$ $$\text{baseCost}(x; q, R) = C(q + x \mathbf{1}_R) - C(q)$$

and the claim rule reads a finalized tick $\tau$ against a half-open interval.

A worked example

This section ties the four layers together once, end to end. The goal is not to pick realistic numbers. The goal is to show how the objects compose into one deterministic mechanism.

Assume a market defines bounds $[L,U)=[0,100)$ with spacing $s=1$. Then there are $n=(U-L)/s=100$ ticks, with indices $0,1,\dots,99$.

If a settlement value is $x=42.7$, tick mapping is just "binning":

$$\text{tick}(x)=\left\lfloor \frac{x-L}{s}\right\rfloor = \lfloor 42.7 \rfloor = 42$$

Now take a range $R=[40,50)$, which is ticks $40$ through $49$ under the half-open convention. Range pricing reads from the curve state. At a given state $q$, the range price mass is:

$$p(R;q) = \sum_{i=40}^{49} p_i(q)$$

If a trader buys quantity $x_\text{pos}$ on that range, the fee-free base cost is a state transition on the curve:

$$\text{baseCost} = C\!\left(q + x_\text{pos}\mathbf{1}_R\right) - C(q)$$

Execution is "base cost plus overlay." A fee policy produces an explicit fee amount, and the trade settles as:

$$\text{effectiveCost} = \text{baseCost} + \text{fee}$$

Finally, finality locks the day into one tick. After oracle sampling and the post-settlement decision window, the market is finalized with a settlement tick $\tau$. Claims do not need a counterparty. A claim reads only the position range $[\ell,u)$, the size, and the tick $\tau$. The half-open rule decides whether $\tau\in[\ell,u)$ and pays deterministically.

This worked example is intentionally repetitive: every page in the docs is either defining one of the objects above or explaining what happens when the objects are composed.

Grid meaning

The grid defines settlement meaning. A market does not settle on a floating-point value; it settles on a tick index. Bounds $L$ and $U$ and spacing $s$ define a finite set of tick buckets. The tick mapping rule fixes three edge cases up front:

• boundary semantics: half-open ranges remove overlap at tick edges
• out-of-range behavior: values below $L$ clamp into the first tick; values at or above $U$ clamp into the last tick
• resolution: spacing sets the finest settlement granularity the market can express

The grid turns a continuous question into a finite state space. The protocol can then write a deterministic payout rule in terms of tick membership.

Reference: Market Design.

Curve meaning

The CLMSR curve defines pricing meaning. One global pricing state $q$ induces a normalized tick price vector $p_i(q)$. A contiguous range is priced as a sum of tick prices, and a range trade is a structured update to the same global state.

Two properties follow mechanically:

• all ranges share the same liquidity because they read from the same $q$
• fee-free cost depends only on the start state and end state, not trade order

In particular, a sequence of fee-free trades that moves the state through $q_0 \to q_1 \to \dots \to q_k$ has total cashflow $C(q_k)-C(q_0)$. This is the mathematical core of path independence in CLMSR.

Reference: CLMSR Pricing Curve.

Execution meaning

Execution in v1 is the combination of a state-defined base cost and an explicit fee overlay.

Depth $\alpha$ scales price impact. Higher depth compresses slippage for a given state update; lower depth makes the curve more sensitive. In the current release, depth is fixed per market at creation, but it can differ across markets.

Fees are applied after base pricing. This produces two stable quantities for any trade:

• base cost or proceeds from CLMSR
• effective cost or proceeds after the fee overlay

This decomposition makes execution analysis well-posed: slippage is mechanical movement on the curve, while fees are an explicit overlay.

References: Liquidity Depth and Slippage, Fees and Effective Price.

Finality meaning

Finality defines when settlement meaning is locked. Each market day is anchored at a settlement timestamp $T_\text{set}$ and three timeline windows:

• SettlementOpen sample window: $\Delta_\text{settle}$
• decision window: $\Delta_\text{ops}$
• claim delay: $\Delta_\text{claim}=\Delta_\text{settle}+\Delta_\text{ops}$

Oracle settlement uses a signed pull model. Anyone can submit signed samples during the sample window. A deterministic closest-to-$T_\text{set}$ rule selects a single candidate sample, with a tie-breaker to the past. Finalization is a permissioned state transition that fixes one settlement tick for the day.

Claims read only the finalized tick $\tau$ and the half-open payout rule. If a market is not finalized, claims remain closed.

References: Oracle and Settlement, Market Lifecycle, Positions and Payouts.

Accounting coupling

Maker-side accounting is discrete in v1. Trading moves the curve continuously during the day, but maker-side results are realized once per day at the batch boundary after settlement. This couples three objects to the same day key:

• a finalized settlement tick
• a payout reserve escrow for claimable positions
• a maker-side accounting update that realizes net results and fees

References: LP Vault and Daily Batches, Capital Stack and Fee Waterfall.

Trust surfaces

Signals v1 is transparent but not fully trustless. The mechanism surfaces are deterministic given explicit assumptions, but two assumptions remain external:

• oracle truth: signatures and timing rules can be checked, but data truth is external
• governance authority: upgrades and permissioned lifecycle actions are a trust surface in v1

References: Trust & Safety Overview, Governance and Trust Model, Failure Modes and Fallbacks, Threat Model, Known Limitations.

Where the definitions live

Signals uses the same idea from two angles: an English-level statement of what the mechanism does, and a formal definition of how the state transition is computed. When reading the docs, treat the following pages as definition sites.

Concept	Definition site	What is being fixed
Grid and tick meaning	Market Design	tick mapping, spacing alignment, half-open range semantics
Curve and base pricing	CLMSR Pricing Curve	$C(q)$, $p_i(q)$, range trades as $q\to q+x\mathbf{1}_R$
Depth and slippage	Liquidity Depth and Slippage	how $\alpha$ scales price impact, small-trade approximations
Fees and effective price	Fees and Effective Price	fee overlay definition and how it composes with base pricing
Finality and timing	Market Lifecycle	day phases, time gates, claim delay, state machine
Oracle candidate rule	Oracle and Settlement	admissible samples, deterministic candidate selection, tick finalization
Payout semantics	Positions and Payouts	half-open payout rule as a function of settlement tick

Most other pages should be read as implications and composition. They are useful, but they are not where meaning is first defined.

For notation and exact definitions used across pages, see Glossary and Units and Rounding. The full formal specification lives in the Whitepaper.