Factories and lenses

The v24 integration surface

• PvpAMMFactoryV24 creates and registers price-market pools.
• Each pool is an ImmutablePoolProxyV24 bound to one implementation. The proxy is not upgradeable.
• RouterKernelV24 executes guarded actions for factory-registered pools.
• PoolReadLensV24, LiquidityReadLensV24, and PvpV24QuoteLens provide bounded reads and execution-aligned quotes.

Current v24 pools report pool version 24, revision 0. Their compatible components must match the expected schema and identity. Each deployment belongs to a cohort, and every pool records its creation identity: chain, schema, cohort, market key, implementation, and factory.

Market keys and pool creation

A pool is registered by marketKey, a hash of the chain ID, schema set, market ID hash, and collateral. The factory derives and checks the key on every creation path, and getPool(marketKey) resolves the registered pool.

Creation has two paths:

• Governance (createGovernanceMarket, owner-only): governance supplies the oracle, risk profile, fee profile, and pool configuration.
• Bonded (createMarketWithBond): a creator locks the configured bond and receives a pool built from governance-approved presets.

Both paths verify the oracle against the collateral policy, predict the pool address through CREATE2 with the cohort salt, and require the predicted address and registration slot to be vacant. Bonded creators receive no pool role. A bond can be withdrawn after its lock expires, or slashed by governance while it exists. Slashing does not remove the pool.

Governance can flag a market as verified. The flag is curation metadata only: it grants no pool role and does not change fee eligibility.

The factory is not a market directory. To discover markets, use the active deployment manifest, product configuration, an indexer, or factory events. Use the factory to confirm the pool for a known market key.

Guarded execution through the router

Pools accept routed actions from the bound RouterKernelV24. Actions carry expected digests, deadlines, and action-specific bounds such as price, payout, protocol fee, debt, Safety Reserve use, and uncovered debt. Quotes do not reserve state; execution-time state is authoritative. See Orders and execution.

Version-pinned lenses

The Lens Set separates these responsibilities:

• PoolReadLensV24 returns pool state and funding views. PositionReadLensV24 provides position pages and deferred-claim views.
• LiquidityReadLensV24 returns lot pages, per-lot entitlement views, and LP aggregates.
• PvpV24QuoteLens mirrors supported write actions, including opens, closes, liquidity adds and removals, fee and Funding claims, liquidation, and recovery actions.

Before decoding, each lens validates that the pool was created by the bound factory, matches the cohort, reports the expected version and revision, and resolves back through getPool(marketKey) to the same address. A pool that fails any check reverts. There is no fallback to v22 or v23 lens decoding.

Quote results carry a snapshot envelope with the accounting, custody, and config digests used for the quote. Carry those digests into the write action: a mismatch reverts instead of executing on stale assumptions.

Market policy read

Each pool also exposes poolMarketPolicyV24() directly on the pool address. It returns one PoolMarketPolicyViewV24 built from a single read snapshot:

• funding: the same stored and planned Funding projection that poolFundingProjectionV24() returns.
• fundingConfig and modelRates: the active FundingRateConfigV24 and the current-model annualized long and short rate indication.
• eligibleLpFundingValue: the LP value that would carry Funding at that snapshot.
• effectiveMaxLeverageWad, newRiskEnabled, riskProfileHash, overlayHash: the effective trader leverage cap (the smaller of the risk profile and overlay caps) and the risk identity behind it.
• readAt, oracleObservedAt, oracleValidUntil, oracleStatus: the read time and the oracle state used for the snapshot.

modelRates is an indication only. It is computed with zero elapsed time, so it represents no accrued Funding and does not prove that Funding is charging. Check the clock state and eligible weight in funding.stored to distinguish a paused or non-chargeable market from a true zero rate. The lens set does not wrap this view; call it on the pool.

Deployment availability

Contract support in the committed source does not prove a live deployment. At this baseline, v24 contracts are recorded as deployed, verified, and promoted as the active release pointer on a public testnet (Base Sepolia), with no production network cutover. Obtain factory, router, pool, and lens addresses from the active deployment manifest or product configuration, and confirm the lens set identity before integrating.

Why factories and lenses

• The factory deterministically creates pools and resolves known market keys.
• Immutable proxies fix each pool's implementation identity at creation.
• Version-pinned lenses give apps bounded reads and execution-aligned quotes without duplicating protocol math.
• Digest-bound execution keeps quotes and actions on the same canonical state.