Contract Addresses
This page lists the deployed on-chain contract addresses for Signals v1. The contracts below define the market lifecycle (creation, trading, settlement, and claims), the pricing and fee surface, and the governance-authorized policy configuration changes that affect execution and timing.
Addresses are stable integration anchors. Indexers, UIs, and researchers can use them to associate events and state transitions with specific protocol components.
Network
Signals v1 is deployed on Citrea. The addresses below are the canonical endpoints for the live protocol deployment.
The same address set is used by explorers, indexers, and analytics systems. When protocol behavior is discussed in terms of trades, settlement, fees, or claims, the underlying primitives are the state transitions emitted by these contracts.
Signals v1 uses one canonical address set. When addresses change, the relevant object is an on-chain deployment or upgrade transaction, not a documentation convention.
Contract roles
The protocol separates concerns across a small set of contracts.
- SignalsCore: market state, pricing updates, and settlement finality.
- SignalsPosition: range positions and claimable payouts.
- Signals LP Share: maker share token. Public LP access is private in v1.
- ctUSD: payment asset used for trading costs and payouts.
These roles are conceptual. The on-chain addresses below are the canonical anchors for each role.
Core protocol contracts
| Component | Address | Purpose |
|---|---|---|
| SignalsCore (proxy) | 0x516312275875932ec2B53A41df4De02743131729 | Core trading, market lifecycle, settlement |
| SignalsPosition (proxy) | 0x3fbD02f3F5Cf2C1e8d6b94e6F1AD30058972D004 | Position token and range claims |
| Signals LP Share (proxy) | 0x7e27CAaCf3Af6b2e092cFf25D9ac20432162CE18 | Maker share token |
| ctUSD | 0x8D82c4E3c936C7B5724A382a9c5a4E6Eb7aB6d5D | Payment asset |
The LP share token is deployed on-chain, but public LP access is private in v1.
The proxy addresses above are the primary integration anchors. They are the addresses that hold the protocol's storage and emit the canonical event stream. Implementation contracts exist, but they are not stable anchors across upgrades.
Protocol modules
Signals v1 composes behavior through modular contracts referenced by the core.
| Component | Address | Purpose |
|---|---|---|
| TradeModule | 0xA600ec37ab480B45C2d832F7960A2750DF664562 | Trade execution logic |
| MarketLifecycleModule | 0xE121AD8948aD9447Bd0DC2DaA27C5311Da98E934 | Market lifecycle state machine |
| OracleModule | 0x90Be79E7239eEb3BB2Af52a229447bEa3AE77779 | Oracle sample validation and candidate selection |
| RiskModule | 0x713b57E6bf69A97610C2895F0923681fbE7A1bAD | Safety envelope and gating logic |
| LPVaultModule | 0x4D9668646E1f3b53F6d91575eFb202F626D740a1 | Maker accounting and daily batching |
Fee policy contracts
Fee policy is implemented as an explicit overlay contract. Markets can reference different fee policy instances at creation.
| Component | Address | Purpose |
|---|---|---|
| FeePolicy (0 bps) | 0x72d112D17638e3DFD0C7A5B085F345C73d1bD08e | No-fee policy |
| FeePolicy (10 bps) | 0xad75Aa06CE2e9fA5c1A6a321f3D3f47151a04cfA | 0.10% fee policy |
| FeePolicy (50 bps) | 0x01bc8716CB8035e70DA02d67f553b0437990215E | 0.50% fee policy |
| FeePolicy (100 bps) | 0xe134d959F13Ef3F8D0916A8AAD616D60926258D2 | 1.00% fee policy |
| FeePolicy (200 bps) | 0xbe686e79Bb21f83a4dc0cB643128f3AAffC1bFF6 | 2.00% fee policy |
Upgradeable implementations
SignalsCore, SignalsPosition, and Signals LP Share are upgradeable via proxies. The implementations below reflect the current deployed code addresses.
| Component | Address |
|---|---|
| SignalsCore implementation | 0x0feb4a8A313e24D70bfC8BA58fdF1D80d098B774 |
| SignalsPosition implementation | 0x63AA48a8a450782643A319a2a4C52B7dF8a07D3F |
| Signals LP Share implementation | 0x323D7C3d15a483Dc59463807123421f10F7162a4 |
The proxy addresses are the stable integration anchors. Implementation addresses can change across upgrades. When analyzing historical behavior, the regime boundary is the on-chain upgrade transaction that changed an implementation.
Because modules execute via delegatecall, the core proxy address is also the
event origin for module events. For example, PositionOpened and
SettlementCandidateUpdated are emitted from the core address even though the
code lives in module contracts.
Entry points and event surfaces
At the contract boundary, two proxy entrypoints carry most of the public surface:
SignalsCore: trading entrypoints, settlement and finalization entrypoints, module wiring, and global configurationSignalsPosition: the position token and the claim surface
Modules execute via delegatecall, so their events are emitted in the core context. The event surface is therefore a practical map of what happened:
- trading: position open/increase/decrease/close events and fee-charge events
- oracle: sample submission events and candidate update events
- lifecycle: market created/seeded/settled/failed events
- accounting: daily PnL recording and batch allocation events
The exact event names and parameters are part of the on-chain record. Researchers and indexers typically reconstruct state by combining these events with a small set of view calls for current configuration.
Two practical consequences follow from the address layout:
- When analyzing history, the event origin is usually the proxy address, even when the code that emitted the event lives in a module contract.
- When comparing behavior across time, the important boundary is an upgrade transaction that changes an implementation address or rewires a module.
Those boundaries are the regime boundaries of v1. A market can be the same market address and still have different behavior before and after a regime boundary, because the proxy keeps storage stable while code changes.
Deployment contracts
Signals v1 uses deterministic deployment tooling on Citrea. These contracts are part of the deployment surface rather than the trading surface, but they are useful anchors for researchers who want to track deployments over time.
| Component | Address |
|---|---|
| SignalsCreate2Factory | 0x17925299E7E2E044672F8a889F5c35C762a2065e |
| SignalsDeployer | 0x795B4ed8869Fb2172c2c68eA21cCb5FdE6ad7AB4 |
Composition
SignalsCore composes protocol behavior by referencing modules and policies in configuration state. The tables above list the deployed module and policy addresses used by the current deployment.
This split is intentional: the market design and pricing curve semantics stay clean at the core surface, while settlement details, gating logic, fee overlays, and maker accounting are modularized behind explicit contract boundaries.
The modules align with the conceptual split used across the docs:
- TradeModule: trade execution on the shared curve.
- MarketLifecycleModule and OracleModule: timing windows and the two-step settlement flow.
- RiskModule: safety envelope checks at market creation; trade gate hooks exist, but exposure cap enforcement is not active in the current release.
- LPVaultModule: maker-side daily batching and share price updates.
- FeePolicy contracts: explicit fee overlays applied to base pricing.
How to read the contract set
SignalsCore is the entrypoint for market state and trading. It holds the shared pricing state, the market lifecycle state machine, and the finalized settlement tick once settlement completes.
SignalsPosition represents range positions and the claim surface. Positions use the half-open range convention and pay out deterministically once a market is finalized and claims are open.
ctUSD is the settlement asset used to pay trading costs and to receive claim payouts. It is the common accounting unit across markets.
If reading the protocol through transactions, a simple way to partition activity is by "what must change state":
- trading changes the CLMSR state for one market and transfers ctUSD
- settlement changes lifecycle state and escrows a payout reserve
- claims transfer out of the payout reserve once the claim gate is open
- batches change maker-side accounting state once per day
The address list above is therefore not just an index. It is the set of anchors that determine which state transitions belong to the mechanism versus the surrounding tooling.
Related reading: