Governance and Trust Model

Signals v1 uses governance to coordinate upgrades, policy changes, and the permissioned finalization step in the daily lifecycle. It is a core part of the trust model and is visible on-chain.

In v1, governance is a real trust assumption. The protocol makes that explicit: changes are recorded on-chain as state transitions, but governance decisions are not controlled by market participants.

Trust surface in v1

Governance is a deliberately visible trust surface. It exists because certain actions—upgrades, policy adjustments, and finalization steps—require a human decision loop. The protocol exposes that loop rather than hiding it.

In v1, governance should be treated as a first-class component of the protocol, not as external "operations." The on-chain mechanism is deterministic, but the live system still needs an authority surface for upgrades and for permissioned state transitions. Governance is the interface to that authority surface.

Governance is intentionally narrow in scope. It is not used to set prices, pick arbitrary winners, or settle by discretion. It is used to execute explicit state transitions that the mechanism already defines:

• upgrades and configuration changes become active only when executed on-chain,
• settlement finality is an explicit state transition during the decision window,
• and the record of those transitions is public.

The narrowness is important. The protocol is built so that most behavior is deterministic given state. Governance is the boundary layer where the system still needs authority. That authority should be measurable by its on-chain surface, not by implied off-chain power.

Mechanism vs policy

The protocol needs a mechanism to handle upgrades, parameter changes, and finality steps that are not fully automated. Governance is that mechanism. It is the bridge between fixed on-chain rules and evolving market conditions.

The distinction is between the mechanism (fixed math and state machines) and policy (configurable values like timing windows or fee rates). Governance can change policy, but it cannot change the fundamental rules without a full upgrade.

The split can be stated more concretely:

• Mechanism defines semantic meaning: tick mapping, range payout semantics, and the CLMSR state transition rule.
• Policy defines execution conditions and trust surfaces: settlement timeline windows, oracle configuration, risk configuration, vault configuration, module wiring, and the executor allowlist.

This split is the reason governance actions are treated as regime boundaries in analysis. A policy change preserves the mechanism grammar but changes execution conditions. An upgrade changes bytecode and can change grammar itself.

Governance surfaces in v1

Governance touches a small set of concrete surfaces.

Upgrades and wiring

Core entrypoints are upgradeable. Governance can:

• change implementation addresses behind stable proxy entrypoints,
• update module wiring used by the core contract,
• update allowlists and pause state that gate privileged transitions.

These changes can alter observed behavior without changing addresses. The proxy addresses remain stable. The regime boundary is the on-chain transaction that changed bytecode or configuration.

Policy configuration

Policy configuration changes execution conditions. Examples include:

• settlement window lengths anchored at $T_\text{set}$,
• oracle configuration and admissible sample constraints,
• vault accounting configuration and fee split weights.

Policy updates can change effective price, slippage profiles, and settlement timing without changing the meaning of a position.

Market listing and per-market parameters

Market creation is permissioned in v1. Governance can list new markets with specific parameters at creation:

• bounds and tick spacing that define the outcome grid,
• depth parameter $\alpha$ that scales price impact,
• fee policy address that defines the fee overlay,
• timing windows and the settlement timestamp.

These parameters are part of the public market record. Markets can therefore behave differently by construction even under the same global configuration.

Permissioned finality

Finality is an explicit on-chain transition. Governance authorizes the entity that can finalize a market day and, when needed, mark a day as failed.

The primary finalization path is constrained by the oracle candidate selection rule. It writes the selected tick derived from signed data.

The secondary path exists only for failed markets. It writes a settlement value supplied by the permissioned finalizer and converts that value into a tick by the same deterministic mapping rule.

This is a trust surface. It is also a bounded surface. It exists to keep the state machine resolvable under oracle stress rather than to introduce discretionary payout meaning.

What governance can change

• Protocol upgrades and configuration changes.
• Authorization of routine operations that require on-chain finalization.

These actions are executed on-chain and recorded in event logs.

These changes define market conditions. Fee policy, timing windows, and implementations can change the behavior observed at the trading and settlement surface even when the high-level mechanism description remains the same. In the current release, depth and fee policy are specified per market at creation.

Typical governance actions include:

• Updating module wiring and proxy implementations behind stable entrypoints.
• Updating the settlement timeline windows anchored at $T_\text{set}$.
• Updating oracle feed configuration and timing constraints for samples.
• Updating safety and accounting configuration that defines admissible market creation and fee allocation ordering.
• Updating the executor allowlist and emergency pause state.
• Creating new markets with specific grid, depth, and fee policy configuration.
• Executing permissioned lifecycle transitions such as settlement finalization.

Each action has an explicit on-chain activation boundary. Before the transaction, the old regime is active. After the transaction, the new regime is active.

What governance cannot change

• The math of the CLMSR curve without an explicit upgrade.
• The definition of tick ranges and payout semantics without code changes.
• The requirement that changes be visible on-chain.

In other words, governance can move policy and it can replace code, but it cannot pretend changes did not happen. The regime boundary is part of the trust model: when implementations or configuration change, the change is an on-chain state transition with a timestamped activation.

Trust assumption in v1

Governance keys are a critical trust assumption in v1. Policy and implementation changes are public and attributable on-chain; the authority surface is explicit rather than hidden.

This means governance is both a risk and a safeguard: it can respond to failures and upgrades, but it also introduces a trust surface that users must accept.

Governance changes are ordinary on-chain transactions. Configuration state before and after a change, plus the block timestamp, define when a policy became active. Governance actions therefore form regime boundaries in historical analysis.

Signals uses upgradeable proxies in v1. The stable entrypoint addresses are the proxy addresses; implementation addresses can change over time. Governance is the authority that can trigger such changes. Governance and deployment addresses are part of the same trust surface.

Stable entrypoints are part of usability. A trader can integrate against the proxy entrypoint addresses and treat upgrades as regime boundaries rather than as "new contracts." That convenience comes with a trust assumption: the governance authority can change bytecode behind the proxy. The protocol makes that assumption visible by keeping upgrade actions on-chain and attributable.

Contract addresses for the deployed protocol, including current implementation addresses, are listed in Contract Addresses.

Clarifications

• Governance visibility does not imply user control; it implies traceability.
• A policy change can materially affect execution even if the curve is unchanged.
• Upgrade traceability is part of the trust surface: upgrades are state transitions.

Decentralization roadmap

Signals v1 treats governance as an evolving system. The whitepaper describes a progressive decentralization path and its assumptions.

Whitepaper section:

• Change Process & Decentralization