Skip to main content

Changelog

Signals v1 is an upgradeable on-chain protocol. Over time, the same proxy addresses can route to different implementations, global configuration can change, and new markets can be listed with different depth and fee overlays.

This changelog records those regime boundaries at the protocol surface. The goal is to keep historical behavior interpretable:

  • what changed,
  • what behavior it affects,
  • and which on-chain artifacts define the activation boundary.

Kinds of change in v1​

Signals has three categories of change that show up in public behavior.

1) Code upgrades​

Core entrypoints are upgradeable via proxies. A code upgrade changes bytecode behind an existing address and defines a new regime even when the external function signatures are unchanged.

The practical consequence is that "same address" does not imply "same rules." When a proxy upgrades, pricing edge cases, rounding behavior, and settlement state transitions can change.

Upgrade boundaries matter most for:

  • rounding and unit conversions that affect realized debits and credits,
  • settlement state machine transitions and the time-gating of finality and claims,
  • and maker-side accounting rules such as the fee waterfall and batching.

2) Configuration changes​

Some aspects of behavior are configuration rather than code. These updates are on-chain regime boundaries even when no upgrade occurs.

Examples include:

  • settlement window lengths anchored at TsetT_\text{set},
  • oracle configuration and admissible sample constraints,
  • vault accounting configuration and fee split weights,
  • module wiring that selects the active logic for a given surface.

Configuration updates can materially change execution costs and timing while preserving the semantic meaning of positions and payouts.

3) Market creation parameters​

Each market fixes its own grid and economics at creation. These are not "changes over time" for a market, but they are part of the public record and they often explain why two markets behave differently.

Market creation parameters include:

  • [minTick,maxTick)[\text{minTick}, \text{maxTick}) bounds
  • tick spacing
  • depth parameter α\alpha
  • fee policy address used for fee overlay
  • trading window and settlement timestamp

Markets can therefore differ in slippage, fees, and timing without any governance action after creation.

Entry structure​

Each entry is written as a behavior-level change description with concrete anchors.

An entry provides:

  • Activation time: the block timestamp that made the new regime active.
  • Behavior change: what a trader or researcher would observe differently.
  • On-chain anchors: proxy addresses, implementation addresses, and event names that identify the regime boundary.
  • Compatibility notes: whether historical comparisons need to be segmented.

The changelog avoids adjectives and uses mechanical statements. "Fees changed" means "the fee policy address used by new markets changed" or "the fee policy contract implementation changed." "Settlement timing changed" means one of the timeline window parameters changed.

Compatibility and segmentation​

Changelog entries are not only news. They define how historical comparisons must be segmented.

Code upgrades are hard regime boundaries. The proxy address remains stable, but the executed bytecode can change. Historical comparisons across an upgrade should treat pre-upgrade and post-upgrade behavior as different regimes, even when external interfaces look identical.

Configuration changes are regime boundaries for the surfaces they touch. A settlement window change changes when submissions are admissible and when finalization becomes available. An oracle configuration change changes which samples are admissible around TsetT_\text{set}. A vault configuration change can change maker allocation outcomes while keeping trade pricing unchanged.

Market creation parameters are not a time series boundary for a given market, but they are a comparability boundary across markets. Two markets can share the same core contracts and still have materially different execution because:

  • tick spacing changes the granularity of settlement,
  • depth changes slippage scale,
  • fee policy address changes effective price.

This is why changelog entries focus on protocol-level regime shifts, while market-to-market differences are read from the market creation record.

On-chain anchors by change type​

Signals v1 is built to make regime boundaries legible in the public record. Most behavior-level changes map to a small set of on-chain artifacts.

Code upgrades:

  • A proxy upgrade is an on-chain transaction that changes the implementation address behind a stable proxy entrypoint.
  • The stable integration anchors are the proxy addresses. The regime boundary is the upgrade transaction that changes the implementation address.

Configuration changes:

  • Oracle configuration changes emit an OracleConfigUpdated event.
  • Market timing changes emit MarketTimingUpdated or SettlementTimestampUpdated.
  • Fee overlay changes emit MarketFeePolicySet for the affected market.

Market creation parameters:

  • Market creation emits MarketCreated, which pins bounds, spacing, bin count, and the market liquidity parameter.
  • If a fee policy is set at creation, MarketFeePolicySet records the initial policy assignment.

These anchors do not exist to "prove safety." They exist to make historical analysis well-posed. When a new regime begins, the on-chain boundary should be explicit enough that a dataset can be segmented without guesswork.

Current regime snapshot​

Status (as of February 6, 2026): the deployed address set is the canonical anchor for the live regime. It is listed in Contract Addresses.

This is a snapshot entry rather than a historical series.

2026-02-06

  • Change: current deployed regime snapshot
  • Behavior surface: pricing and trading via SignalsCore, positions and claims via SignalsPosition, daily maker accounting via the vault module
  • Deployment anchors: SignalsCore proxy, SignalsPosition proxy, module addresses, and fee policy addresses
  • Compatibility: treat future proxy upgrades and configuration changes as new regimes, even if the proxy addresses remain unchanged

Snapshot addresses are repeated here so the changelog entry is self-contained:

  • SignalsCore proxy: 0x516312275875932ec2B53A41df4De02743131729
  • SignalsPosition proxy: 0x3fbD02f3F5Cf2C1e8d6b94e6F1AD30058972D004
  • Signals LP Share proxy: 0x7e27CAaCf3Af6b2e092cFf25D9ac20432162CE18
  • ctUSD: 0x8D82c4E3c936C7B5724A382a9c5a4E6Eb7aB6d5D

Module set:

  • TradeModule: 0xA600ec37ab480B45C2d832F7960A2750DF664562
  • MarketLifecycleModule: 0xE121AD8948aD9447Bd0DC2DaA27C5311Da98E934
  • OracleModule: 0x90Be79E7239eEb3BB2Af52a229447bEa3AE77779
  • RiskModule: 0x713b57E6bf69A97610C2895F0923681fbE7A1bAD
  • LPVaultModule: 0x4D9668646E1f3b53F6d91575eFb202F626D740a1

Fee policy set:

  • FeePolicy 0 bps: 0x72d112D17638e3DFD0C7A5B085F345C73d1bD08e
  • FeePolicy 10 bps: 0xad75Aa06CE2e9fA5c1A6a321f3D3f47151a04cfA
  • FeePolicy 50 bps: 0x01bc8716CB8035e70DA02d67f553b0437990215E
  • FeePolicy 100 bps: 0xe134d959F13Ef3F8D0916A8AAD616D60926258D2
  • FeePolicy 200 bps: 0xbe686e79Bb21f83a4dc0cB643128f3AAffC1bFF6

Examples of change descriptions​

These are not additional changelog entries. They are examples of the level of precision expected when a regime boundary is recorded.

Example: Listing new markets with a different fee overlay​

Change description: new markets are created with a different fee policy address than earlier markets.

Behavior surface: effective execution price changes for those new markets, because the fee overlay is applied after base CLMSR pricing. Base cost remains a potential difference. Effective cost includes the fee overlay.

On-chain anchors: the market creation transaction emits MarketCreated and an initial MarketFeePolicySet with the new fee policy address. Existing markets retain the fee policy fixed at their creation.

Compatibility: treat fee policy as a market-level regime parameter. Comparing execution across markets should segment by fee policy address.

Example: Oracle admissibility configuration change​

Change description: oracle admissibility constraints are updated. For example, max sample distance or future tolerance changes.

Behavior surface: which signed samples are admissible inside SettlementOpen can change. Candidate selection is still deterministic over the admissible set.

On-chain anchors: OracleConfigUpdated defines the activation boundary and the new constraint values.

Compatibility: settlement behavior should be segmented at the block timestamp where oracle config changed.

Example: Proxy upgrade behind a stable entrypoint​

Change description: the proxy entrypoint address stays the same, but the implementation behind it changes.

Behavior surface: pricing edge cases, rounding boundaries, and settlement state machine transitions can change even when interfaces remain stable.

On-chain anchors: the proxy upgrade transaction and its emitted upgrade event define the activation boundary. The new implementation address defines the new bytecode regime.

Compatibility: treat pre-upgrade and post-upgrade behavior as different regimes.

Concept references: