Governance Journey

Governance in Signals v1 is the public authority surface. It is the mechanism by which code and global policy can change, and it is the mechanism by which a small set of time-gated lifecycle actions are authorized and attributed.

Most protocol interactions are permissionless. Trades, position management, oracle sample submission, and claims are open to any address. Governance exists because v1 intentionally includes an authority boundary: the system is designed to be transparent and mechanically specified, but not fully trustless.

Authority surfaces in v1

Two privileged roles appear throughout v1 contracts.

• owner is the governance address. It can upgrade proxy implementations and update global configuration.
• operator is an allowlisted role. It can execute narrow, time-gated lifecycle actions such as market creation, seeding, and settlement finalization.

The practical meaning is that the protocol has two categories of history. Permissionless actions create user-level history. Governance and operator transactions create regime-level history: they decide which code and which configuration are active for subsequent days.

Surface	Permission model in v1	Primary effect
Trading and positions	permissionless	moves CLMSR state and transfers ctUSD
Oracle submissions	permissionless	posts signed samples during the admissible window
Claims	permissionless	transfers deterministic payouts after finality and delay
Finalization and listing steps	operator	writes time-gated lifecycle transitions on-chain
Code and policy changes	governance via owner	creates regime boundaries via upgrades and config writes

This separation is deliberate. If trading were permissioned, price discovery would be biased toward the authority. If finality were fully permissionless, settlement could become ambiguous in the presence of competing submissions, reorg risk, and timing games. v1 chooses open participation for trading and open submission for signed samples, while keeping the "write final meaning" step attributable through the operator role.

Regime boundaries

Signals uses upgradeable proxies. That design keeps integration anchors stable, but it introduces a required analysis habit: the proxy address alone is not the full meaning of the mechanism. The active regime is the proxy address plus the implementation and configuration that were active at the time.

A regime boundary is any on-chain transaction that changes one of:

• a proxy implementation address,
• module wiring that changes which code executes under a proxy entrypoint, or
• global configuration that changes admissibility or timing.

After a regime boundary, the same calldata can produce different behavior, because it is interpreted under a different configuration or a different code path. The boundary itself is not subjective. It is a concrete transaction that can be indexed and replayed.

This is the core reason governance is part of the protocol surface. A system with upgradeable proxies does not have one static "the code." It has a sequence of regimes, each with its own bytecode and configuration, all anchored by an on-chain activation point.

Common governance actions

Governance shows up as concrete callable surfaces on the core contracts. The exact set can evolve across upgrades, but the pattern is stable: configuration and wiring are explicit, and privileged actions are attributable.

Typical examples include:

• module wiring updates, which change which module bytecode executes through delegatecall under the core proxy
• settlement timeline updates, which move the stage boundaries around $T_\text{set}$ and therefore change when trades and submissions are admissible
• oracle configuration updates, which change which signed samples are admissible for candidate selection
• risk and accounting configuration updates, which change admissibility at market creation and the daily fee allocation math at the batch boundary
• operator allowlist updates, which change which addresses can execute the permissioned lifecycle actions
• pause and unpause actions, which disable and re-enable guarded entrypoints

Governance also affects markets indirectly. New markets can be listed with specific depth and fee policy at creation. Even when the mechanism semantics are stable, different market instances can have different economics because they were created with different configuration.

The operator role is important to call out separately because it is the "daily bridge" between time gates and recorded meaning. In v1, the operator can:

• create markets and seed them into a well-formed initial curve state
• execute primary settlement finalization after the submission window ends
• execute secondary or failure paths when the primary settlement path cannot be completed

These actions are not hidden, and they are not discretionary in the same sense as off-chain administration. They are time-gated state transitions. For example, primary finalization can only happen after the submission window closes:

$$t \ge T_\text{set} + \Delta_\text{settle}$$

and claims can only happen after both finality and the claim delay:

$$t \ge T_\text{set} + \Delta_\text{claim}$$

When these transitions occur, they create legible checkpoints in the event stream: the market moved from one lifecycle stage to the next.

Two concrete examples

Example A: settlement timeline update

Assume a governance transaction updates the settlement timeline configuration. For market days whose $T_\text{set}$ fall after the update, the boundary between trading, oracle submission, and finalization shifts.

This does not change payout meaning or base pricing meaning. It changes the time gates that decide which transactions revert. The activation point is the governance transaction itself, and the behavioral difference is visible as a shift in which timestamps are admissible for each phase of the day.

A useful way to internalize this is to think in terms of "validity windows." Before the update, a trade at timestamp $t$ might be valid. After the update, the same timestamp might fall outside the admitted trading window and therefore revert. The change is not about fairness or discretion. It is about which timestamps the state machine admits.

Example B: proxy implementation upgrade

Assume a governance transaction upgrades the SignalsCore implementation. Immediately after the transaction is mined, the same proxy address begins executing new bytecode for subsequent calls.

That is a regime boundary even if the ABI remains compatible. From that point on, trade execution, settlement behavior, and accounting updates must be read as the behavior of the new implementation. The upgrade boundary is on-chain and can be tied to a block height and transaction hash.

Example C: oracle admissibility update

Assume a governance transaction updates oracle admissibility constraints. In v1, settlement candidates are derived from submitted signed samples, but not every sample is admissible. Timing windows and distance constraints decide which payloads can participate in candidate selection.

After an oracle configuration change, the candidate selection rule is the same kind of rule, but it is applied to a different admissible set. This can change which sample becomes the settlement candidate on days when submissions are near the boundary of admissibility.

Reading governance history

When reconstructing protocol behavior, a useful workflow is:

1. Anchor on the proxy addresses in Contract Addresses.
2. Segment history on upgrade and configuration transactions.
3. Interpret each segment under the implementation and configuration that were active inside that segment.

This is the minimal discipline required to make comparisons meaningful across time. A week of data is only comparable to another week of data when both lie inside the same regime, or when the regime boundary is explicitly modeled.

In practice, the segmentation step is usually one of:

• record all proxy upgrades and treat each upgrade as a new regime interval
• record key configuration writes that affect timing and admissibility and treat them as boundaries for lifecycle analysis
• record module wiring changes, because wiring changes can move the code path that executes under the same public entrypoint

Signals includes a changelog precisely because regime boundaries matter. Human readable summaries are helpful, but the on-chain boundary remains the source of activation truth.

Clarifications

• Governance does not rewrite the CLMSR cost function as an arbitrary policy. Changes are expressed as on-chain configuration and code boundaries.
• Permissioned finality is a time-gated state transition that records the settlement tick. It is part of the trust model, not an off-chain interpretation.
• Transparency is the requirement that these boundaries are observable and attributable in the on-chain record.

Related sections:

• Governance and Trust Model
• Contract Addresses
• Known Limitations