Roles in Signals v1
Signals v1 separates roles by what participants are trying to do. Most user actions are permissionless, while a small set of authority actions are permissioned in v1. This split keeps trading open while keeping finality and policy changes attributable on-chain.
The split is not a UI convention. It is enforced in contract code and visible in transaction history. Trades and claims look like ordinary user transactions. Upgrades, market listing steps, and settlement finalization look like authority transactions because they are.
Two concrete roles appear throughout v1 contracts:
owner: the governance address that can upgrade and change configuration.operator: an allowlisted role that can execute time-gated lifecycle actions such as market creation, seeding, and primary settlement finalization.
The existence of privileged roles is not hidden. It is part of the v1 trust model and is legible on-chain through access control, configuration state, and events.
The table below is the practical map of "what can happen, who can do it, and what to look for on-chain."
| Surface | Permission model in v1 | What it looks like on-chain |
|---|---|---|
| Trading and position management | permissionless | trade events plus curve state updates |
| Claims | permissionless | claim events plus ctUSD transfers |
| Oracle sample submission | permissionless | sample submission events with signature-checked payloads |
| Settlement finalization | operator, authorized by governance | a time-gated state transition that locks one tick |
| Market listing and seeding | operator, authorized by governance | market created and seeded events before trading opens |
| Upgrades and global configuration | governance via owner | explicit regime boundary transactions |
Traders
Traders take range positions and later claim payouts. Their activity is what moves the shared pricing curve and updates market beliefs. In practice, traders are interacting with a curve rather than matching against individual peers, so trade size and timing directly influence slippage and effective price.
Traders can open, adjust, or close positions before settlement. Once the oracle window opens, trading stops and the outcome is determined by finality rather than by further trades.
Trading is still time-gated. Position entrypoints require the market to be seeded, not yet settled, and inside the market's trading window:
Execution also uses explicit bounds. Buys provide maxCost and sells provide
minProceeds. Those values are execution constraints that cause a revert if the
effective execution amount is worse than the bound.
Range positions are transferable claims on a deterministic payout rule. A position does not depend on a counterparty at settlement time. It depends only on the finalized settlement tick and the half-open interval semantics.
At the surface level, trading is interaction with three stable objects:
- the grid defines settlement meaning and position semantics
- the curve defines fee-free base cost as a state transition
- overlays define effective price and phase gates for the day
The mechanism-level implication is that a trade is analyzable from chain state. The executed cost is not a dealer quote. It is the result of moving a public state from to and applying a fee overlay. Slippage is a mechanical property of that state movement, and the transaction calldata contains an explicit bound that either admits the trade or forces a revert.
This is the practical meaning of a protocol-level market: the rules are in the contracts, and the record of trades and settlement is on-chain.
LPs
Maker capital underwrites liquidity depth. Deeper liquidity reduces price impact and makes large trades more feasible. LP access is private in v1, but the relationship between maker capital and liquidity depth is fundamental to how the system works.
Maker capital is realized on a daily cadence. Pricing is continuous, but maker accounting is discrete: maker-side gains, losses, and fee allocation are realized once per market day at a batch boundary. This design makes maker exposure a clear unit: an LP position either carried a full market day or it did not.
Conceptually, the maker role is the balance sheet behind the curve:
- trades move the pricing state during the day,
- settlement finalizes one tick,
- the daily batch realizes the maker-side result and updates share accounting.
Two details matter for interpreting maker capital even when access is private. First, maker exposure is aligned to the daily boundary. There is no concept of midday entry or exit that avoids intraday risk. Second, maker accounting is coupled to the same day key as settlement and claims. This makes the accounting history a sequence of discrete, comparable daily checkpoints.
Governance
Governance authorizes upgrades and configuration changes, and it authorizes the operator set that can execute time-gated lifecycle actions. These actions are permissioned but fully on-chain and attributable, which makes governance part of the trust model rather than a hidden operational layer.
Governance actions can change global configuration such as settlement timeline windows and oracle configuration. New markets can also be listed with specific depth and fee policy at creation. These changes are visible on-chain.
Governance also decides which addresses are authorized as operators. This is the mechanism by which the system can keep trading open while keeping finality and configuration changes attributable.
Governance also defines version boundaries. Signals uses upgradeable proxies in v1. Proxy entrypoints remain stable while implementations can change through governance-authorized upgrades. This preserves stable integration points while keeping upgrade activity explicit in the on-chain record.
Two points prevent a common misunderstanding. Permissioned finality is not a claim about oracle truth. The settlement tick is determined by a deterministic candidate rule applied to admissible samples. The permissioned action is the time-gated state transition that records the tick. Upgrades, likewise, are not a "hidden switch." They are explicit regime boundaries: behavior can change, but the boundary is a concrete on-chain transaction that can be indexed and reasoned about.
Oracle reporters
Settlement data is signed off-chain and can be submitted on-chain by anyone during the oracle window. This keeps data submission open while still allowing signature-checked data sources.
Submission openness reduces single‑relayer risk: if one relayer is offline, another participant can carry the same signed data on-chain.
The submission role is intentionally narrow. Submission can carry data on-chain, but it does not define truth. Truth is an external assumption and is addressed in the trust model.
Two roles are therefore distinct:
- Signer: the entity that produces a signature over a data point.
- Submitter: the entity that posts that signed data on-chain.
The protocol checks signature validity and timing rules. It does not have an on-chain way to prove the underlying data source is "true."
The practical implication is that censorship resistance comes from two independent layers. The signer set determines what payloads are acceptable. Permissionless submission determines whether a particular relay is required. A single relay going offline does not prevent settlement, provided a valid signed sample exists and someone submits it within the admissible window.
Access model
High-level access boundaries.
- Trading, position management, claims, and oracle sample submission are open to all.
- Settlement finalization is executed by a governance-authorized transaction.
- Upgrades and configuration changes are executed on-chain and publicly traceable.
This model balances open participation with explicit finality and publicly attributable operations.
The boundary is intentional. Trading is permissionless because price discovery depends on open participation. Finality is permissioned in v1 because settlement must be explicit and time-gated, and v1 includes a governance trust surface by design. The on-chain record makes the split legible: user actions appear as ordinary transactions, and policy or finality actions appear as governance transactions.
A simple day through the roles
- Morning: traders open and adjust positions; the curve moves with each trade.
- Settlement time: anyone can submit signed oracle data.
- Decision window: the governance-authorized step finalizes the candidate.
- After finality: traders claim payouts; accounting updates the day’s result.
Related sections: