Known Limitations

Signals v1 makes deliberate design choices that constrain what the protocol can do. These are boundaries that keep pricing, settlement, and accounting well-defined.

Daily finality

Signals v1 settles once per day rather than continuously. This keeps accounting clean but means outcomes are not finalized intraday. Claims become meaningful only after finality and the claim delay.

This cadence is a structural constraint. A market can reflect new information through trading during the day, but the protocol does not commit to a final tick until the daily settlement step completes.

The daily boundary also couples markets and accounting. Maker-side PnL and fee allocation are realized once per market day. This yields a clean discrete ledger, but it also means "intraday maker equity" is not an on-chain object in v1.

This limitation also shows up in data products. A time series of prices exists intraday, but a time series of maker NAV does not. Maker state is updated at the boundary and is therefore defined as a sequence indexed by day keys.

Discrete outcome grid

Signals v1 prices outcomes on a discrete tick grid. This makes pricing computable and settlement unambiguous, but it means resolution is limited by tick spacing.

A finer grid increases resolution but changes the shape of price impact. A coarser grid reduces resolution but makes settlement boundaries simpler.

The grid also fixes boundary semantics. Positions use half-open intervals, so a settlement value that lands exactly on an upper bound is treated as outside that range. This avoids overlap between adjacent positions, but it is a real convention that affects boundary outcomes.

The grid also makes discretization error explicit. The protocol settles on a tick, not on a floating-point value. Market bounds and spacing define the maximum settlement granularity, and the clamp rule defines out-of-range behavior. These conventions are part of the market contract.

Discrete settlement also implies a data-quality constraint. Tick spacing can be finer than the information quality of the underlying data stream. When that happens, the mechanism is still deterministic, but the perceived boundary may be noisy. The limitation is not computational. It is informational.

Single settlement asset

Signals v1 uses a single settlement asset for payouts (ctUSD). That keeps accounting coherent across markets and days, but it also means the protocol does not settle natively into multiple collateral types.

The single asset choice makes system-wide accounting and fee waterfalls legible. It also constrains how markets can be composed against different collateral curves. Multi-asset settlement introduces cross-asset conversions that are not part of v1.

Single-asset settlement is also a governance and design constraint. It reduces the space of assets that must be trusted for solvency and accounting, but it means the protocol does not express native multi-collateral risk in v1.

LP availability

Public LP access is private in v1. Maker exposure and batching are described in the docs as part of the mechanism surface, but public participation is not open.

This is a product limitation, not a theoretical one. Maker capital and the capital stack exist in the protocol design because depth must be underwritten by real economic capacity. Public access to that surface is a separate step.

This limitation affects how to interpret "depth" as a public object. The curve is public and the pricing state is public, but the ability to join the maker capital stack is not open. Depth is therefore a mechanism property underwritten by private maker participation in v1.

Reliance on external oracle data

Settlement depends on signed oracle data. The protocol can check signatures, but it cannot make the oracle truthful. This is an explicit trust assumption in v1.

Finality is deterministic given signed data, but the data source itself is outside the chain's control.

Oracle timing is also a constraint. Settlement is anchored to a moment. If data is delayed or ambiguous, the protocol will delay finality rather than finalize into an unclear outcome.

The signed pull model reduces dependence on a single relayer, but it does not eliminate the need for the oracle stream to exist and be coherent around the settlement timestamp.

Oracle dependence also creates an information asymmetry constraint. Settlement is deterministic given signed data, but the production of that data is external. This is a trust boundary by design, not a bug to be patched by contract logic.

Governance involvement

Governance authorizes routine operations and upgrades. This adds a trust surface that defines an authority surface for v1. Global configuration (settlement timeline, oracle configuration, safety and accounting configuration, module wiring, executor allowlist) and implementations can change via governance transactions. In the current release, depth and fee policy are specified per market at creation.

Even when governance is functioning correctly, governance creates regime boundaries. Execution behavior can change across time because global configuration or implementations changed, even though the high-level mechanism description is unchanged.

Market creation and settlement finalization are also authorized actions in v1. The protocol does not accept permissionless market creation in the current release. This is a limitation relative to designs that treat market listing as a fully permissionless surface.

Permissioned finality is also a limitation relative to fully automated or fully permissionless settlement designs. The permissioned action is explicit on-chain, but it is still an authority surface.

Chain liveness dependence

Signals v1 is an on-chain protocol. Trading, settlement, and claims require the chain to process transactions. If the chain is congested or halts, finality and claims are delayed. The protocol does not "complete off-chain" during liveness failures; it waits for the chain to resume.

In practice, the timeline is expressed in timestamps, but state transitions are still gated by mined transactions. A claim delay can elapse while finalization is still pending if the chain does not include the finalization transaction.

Chain liveness also interacts with fair execution. Even when pricing is path-independent at the fee-free level, the inclusion environment can reorder transactions and change the realized execution point on the curve.

Mempool execution environment

Signals trades are ordinary transactions in an open execution environment. Adversaries can observe transactions before inclusion and can attempt to front-run, back-run, or reorder trades. CLMSR pricing is path independent at the level of base cost, but execution can still be affected by state changes between submission and inclusion.

This is a limitation shared by most on-chain trading systems. Signals does not assume private order flow, and it does not rely on off-chain matching to hide execution.

This limitation is not avoided by the CLMSR mechanism. CLMSR makes cost well-defined given a state update, but it does not eliminate the fact that the state update is chosen by inclusion ordering.

Upgradeability in v1

Signals v1 uses upgradeable proxies for core contracts. This is a deliberate v1 choice that allows fixes and iteration, but it is also a limitation: the deployed bytecode can change over time via governance.

The upgrade surface is part of the trust model. A protocol that can upgrade can respond to failures, but it also requires users and researchers to treat upgrades as regime boundaries.

Upgradeability also affects interpretability over time. A historical trade can be analyzed from on-chain events and state transitions, but the implementation that produced those transitions can change across upgrades. v1 treats upgrades as explicit regime changes rather than as invisible patching.

Upgradeability is a deliberate v1 posture. It allows iteration and emergency response, but it necessarily increases the importance of the changelog and the deployment record. A stable proxy address is a usability feature, not a guarantee of immutable rules.