Skip to main content

Protocol Transparency

Signals v1 is designed to be observable. The protocol does not rely on a private matching engine or a private accounting service to define prices, settlement, or claims. Pricing is a state transition, settlement is a state transition, and daily accounting is a state transition. Those transitions are the protocol record.

Transparency in Signals has two distinct objects:

  • Mechanism outcomes: the state transitions that implement pricing, finality, and claims for each market day.
  • Regime boundaries: the state transitions that change policy or code, such as configuration updates, module rewiring, and proxy upgrades.

Dashboards and indexers are derived views. They can be useful, but they are not additional sources of truth. The chain record is the canonical history because it is the thing that actually determines what happened.

Three transparency layers​

Signals exposes the mechanism through three layers that fit together.

Code is the executable rule set. Published source and deployed bytecode define the mechanism for a specific regime. When a proxy is upgraded, the code layer changes at a concrete activation point.

State is the current configuration and market status. Bounds, spacing, timestamps, depth, fee policy references, lifecycle flags, the finalized tick, maker-side accounting state, and request queues all live in on-chain storage.

Events are the historical labels for state transitions. A market day is not an inferred story. It is a sequence of emitted events plus the state updates they correspond to.

The key detail for Signals is that the event origin is usually the core proxy address, because modules execute through delegatecall. Module bytecode can change across upgrades, but the address-level integration anchor stays stable.

That proxy-centric layout changes how transparency should be read. "The core contract address" is the anchor for history, while "the current implementation" is the anchor for execution. Both are on-chain, and both matter. The proxy provides stable integration and a stable event origin. The implementation and configuration define what those events and state transitions mean in a given time interval.

Reconstructing a market day​

One way to read the protocol is to treat a market day as a log with explicit phase gates. The exact event names evolve across upgrades, but the structure is stable across regimes.

1. Start from the market definition​

A market definition fixes the grid and the schedule. The canonical objects are:

  • bounds [L,U)[L,U) and spacing ss, which imply a finite tick count
  • settlement timestamp TsetT_\text{set} and the time gates around it
  • the depth parameter α\alpha that scales price impact on the shared curve
  • a fee policy reference, which defines the fee overlay

The grid is not cosmetic. It defines settlement meaning. The schedule is not a UI calendar. It defines which transactions are admitted by the lifecycle checks.

A practical way to anchor a market day is to read the market configuration first and then read the event stream. Configuration tells what the mechanism will do. Events tell what it did.

2. Read trading as state movement​

Trades move one market-local CLMSR state. The record of a trade includes:

  • the range being traded, expressed in lower and upper ticks
  • the signed direction, buy or sell
  • the size in position units
  • the execution bound, maxCost for buys or minProceeds for sells
  • the ctUSD transfer that settles the effective cost or proceeds

The execution bound is part of the on-chain surface. It turns slippage from a UI preference into calldata. A trade either executes within the bound or it reverts.

Base pricing is defined by the cost function difference:

ΔC=C(qafter)−C(qbefore)\Delta C = C(q_\text{after}) - C(q_\text{before})

Fees are an explicit overlay on top of base pricing. In the simplest form, effective cost is:

effectiveCost=ΔC+fee\text{effectiveCost} = \Delta C + \text{fee}

This decomposition is the transparency object. Slippage is the mechanical cost of moving the curve. Fees are the policy overlay. Both are part of execution, and both are recorded through state and events.

For historical reconstruction, there are two common approaches.

First, if the event stream includes enough information about the state update, trades can be replayed as state transitions to reconstruct qq over time. Second, if a reader prefers not to replay, the chain can be queried at historical block heights to read pre-trade and post-trade state directly. Both approaches are mechanically defined. They differ only in where the computation is performed.

In both cases, the transparency point is the same: the curve is state, and execution is a function of state. The protocol does not hide trade pricing in off-chain order matching.

3. Read settlement as a deterministic lock​

At settlement time, signed oracle samples are admissible only inside the submission window. Submission is permissionless, but admissibility is not. The protocol enforces signature and timing constraints.

Among admissible samples, candidate selection is deterministic: the candidate is the admissible sample closest to TsetT_\text{set} under absolute timestamp distance, with a tie-break toward the past.

Finality is the on-chain moment when the day becomes a single tick. Once the finalization transaction is mined, the settlement tick is locked and does not change. From that point onward, claims are defined by the finalized tick and the position range.

Two details are useful when reading settlement history.

First, finality is separate from submission. Many samples can be submitted. Only one sample becomes the candidate under the closest-to-TsetT_\text{set} rule. Second, finality is separate from truth. The protocol can validate that a signed sample is admissible. It cannot validate that the external data source was correct. That separation is what makes the trust boundary explicit.

4. Read claims as deterministic transfers​

Claims are not an off-chain matching step. They are transfers out of an escrowed payout reserve after finality and a claim delay gate.

For a position of size xx on range [ℓ,u)[\ell,u), payout is:

Payout={x,τ∈[ℓ,u)0,otherwise\text{Payout} = \begin{cases} x, & \tau \in [\ell, u) \\ 0, & \text{otherwise} \end{cases}

The inputs are a tick and a range. Trade history does not enter the payout function.

For reconstruction, claim activity is visible as a combination of claim events and ctUSD transfers. The claim surface is the point where "market meaning" turns into accounting reality: claims reduce the escrow reserve and increase the claimant balance. The transfer history is therefore part of the mechanism history, not an application detail.

5. Read daily accounting as one checkpoint​

Maker-side accounting is discrete in v1. Intraday trades move the curve continuously, but maker-side PnL and fee allocation are realized once per day at the batch boundary. LP access is private in v1, but the accounting state transition is public.

Batch processing emits events for the daily allocation and updates maker NAV and share price. Deposit and withdrawal requests are processed at batch prices, not midday prices, which makes exposure a day-level object rather than a timing advantage.

The fee allocation step is also a transparency object. Fees are generated by trades during the day, then allocated across the capital stack by a deterministic waterfall. The specific destinations depend on configuration, but the structural constraint is conservation: fee allocation is redistribution, not creation.

The daily checkpoint is the bridge between continuous trading and discrete solvency accounting. It is the moment when the system commits to one daily outcome and records it in a way that can be compared across days.

Regime boundaries as part of transparency​

Signals uses upgradeable proxies and modular execution, so transparency must include regime boundaries, not just day-level outcomes.

The minimal regime boundary set is:

  • proxy implementation upgrades
  • module wiring changes
  • global configuration changes that affect timing or admissibility

These boundaries are all on-chain and attributable. When a boundary exists, a behavioral comparison across time is meaningful only if the boundary is modeled. The same proxy address can behave differently under a different implementation.

The Changelog is a human-readable guide, but the activation truth is the on-chain transaction that changed code or configuration.

In practice, modeling regime boundaries usually means attaching a regime label to each event based on block height. The label is derived from the last upgrade or configuration boundary before the event. This turns the on-chain record into segments that can be compared without mixing incompatible execution rules.

Limits of transparency​

Transparency does not mean that every relevant fact is provable on-chain. Two classes of uncertainty remain outside the chain in v1.

Oracle truth is external. The protocol can validate signatures and timing rules, but it cannot prove that the underlying external data source was correct.

Governance intent is external. The on-chain record shows what was executed and when it became active, but it does not prove that the decision process was optimal or aligned.

Signals treats these limits as explicit boundaries. The mechanism itself is mechanically specified and publicly observable. The remaining trust surfaces are handled as part of the v1 trust model rather than as hidden assumptions.

Related sections: