Reference

Contract inventory

This page lists every production Solidity source by area. The contract interaction reference documents the entrypoints of the contracts users and keepers call; this page adds the caller and trust boundaries of the deployment helpers, delegate modules, and libraries that reference does not cover, the SecurityPoolUtils previews, and the Uniswap contracts a testnet deployment uses.

Caller and trust boundaries

Deployment helpers are not interchangeable with canonical protocol discovery. Several are intentionally permissionless and bind the caller into each deployed address, through a caller-namespaced salt or the caller in the init code; an application must discover canonical instances through SecurityPoolFactory, recognized security pools, and recognized forker events rather than treating every factory-created address as canonical.

Module	Direct caller boundary	Canonical-use boundary
`SecurityPoolPortfolio`	An immutable admission policy, question horizon, economic configuration and canonical configuration seed define the portfolio. After construction, four permissionless `prepareNext()` transactions initialize settlement, reporter/fork modules, capital, then the shared feed and activation. `setupStage == 4` is required before accepting user funds or risk. Anyone may register an allowed, open question in the unforked origin universe. `getPool(questionId, universeId)` resolves the registered lineage through the configured factory. Each universe has one capital ledger and one shared REP/ETH feed.	The central settlement book owns question cash and supply accounting; the capital ledger owns each provider’s REP and commitments; the reporter ledger separately owns report escrow. Native question contracts expose shares and reporting. Verify the factory and module bindings independently. See the portfolio model.
Question admission policies	`ISecurityPoolQuestionAdmissionPolicy.isQuestionAllowed(portfolio, universeId, questionId)` is a read-only approval check. `SecurityPoolOpenAdmissionPolicy` always approves. `SecurityPoolFixedAdmissionPolicy(universeId, questionIds)` fixes a nonempty, duplicate-free list at construction with no mutation authority. Its paginated getter returns at most 64 entries.	Policy approval is required for registration and purchase, including reuse of a registered question. Denial or a failed policy call does not block exits, claims or fork recovery. The UI offers the open and fixed policies; the contract API permits other policies.
Portfolio economic configuration	`EconomicsConfig` fixes `purchaseFeeBps` (at most 10,000), `annualFeeBps`, `minimumPurchaseFeeAttoEth`, positive `minimumCommitmentAttoEth`, `minimumOutcomeRate`, positive `rewardVestingSeconds`. Read these immutable settings from the portfolio’s corresponding getters. The security multiplier comes from the canonical seed.	Each provider selects its own health target through `setHealthTarget`. Raising it on a live position requires a fresh price and sufficient backing. `depositAndSetHealthTarget(amount, targetHealthFactorBps)` adds REP and updates the target atomically, applying the same backing check to live target increases. Lowering a target does not increase commitment. The protocol’s liquidation requirement remains unchanged.
`SecurityPoolCapitalLedger`: provider accounts	`depositFor(owner, amount)` is callable only by that owner and adds REP to their entire live position, or to idle principal when they have no commitment. `setCommitment(commitment)` sets the owner’s whole ETH commitment K, backed by all deposited REP C. Without a pending retirement request, raising or keeping K applies at once, subject to a fresh price and the owner’s health target; a raise must also fit the accepted report’s funded exposure limit. `setCommitmentWithReport(reportId, commitment)` can instead prove coverage for a raise using an independently settled, fresh report. Its conservative collateral floor stays attached to the owner until the next canonical price epoch, which must cover actual aggregate exposure.	Each owner has at most one live position in a portfolio universe, active or retiring, with exact C/K amounts. `ownerCollateral(owner)` returns deposited principal, commitment and currently withdrawable principal, excluding ETH and REP earnings. The chosen health target controls authorization, takeover receipt and pledged-principal withdrawal. Liquidation uses the protocol floor, whose security multiplier is at least 10,500 basis points.
`SecurityPoolCapitalLifecycleDelegate`	Each capital ledger creates its own immutable delegate for authorization, owner withdrawals, earnings claims and fork-choice export, import and backing release. It shares the ledger’s storage layout through `SecurityPoolCapitalState`. Mutations execute in the bound ledger’s context; direct mutation calls and delegate calls from another host revert.	The ledger’s entrypoints retain caller permissions, reentrancy guards and price/checkpoint requirements. Principal and earnings stay in the ledger. Preparation reports cache prices without starting imported positions’ health history. `finishForkImport` seals the funded imports and records a health observation only if the cached price is still valid. The delegate’s `ledger()` getter identifies its sole host.
Principal withdrawal and retirement	`withdrawPrincipal(amount, recipient)` withdraws idle principal without a price requirement. A live position must be unforked and have a fresh price; its remaining REP must cover K at `ownerConservativePrice(owner)`, the protocol multiplier and the saved health target. That price includes an unexpired growth-proof floor when present. Lowering K with `setCommitment` at a fresh price first cures an underwater position at once and queues the rest of the reduction for retirement; at a stale price the whole reduction is queued. Zero requests a full exit; a nonzero residual and the queued reduction must each meet `minimumCommitmentAttoEth`. The owner cannot change or cancel a pending request through `setCommitment`: until it is served, `setCommitment` accepts only the pending value, which leaves the request in place and cures an underwater position at a fresh price.	`serveRetirement(0)` serves the closed current cohort before the next. Full-exit subtrees close lazily; it updates at most one partial-retirement boundary per call. `serveRetirement(positionId)` completes that position’s entire queued reduction only when spare healthy capacity also covers all healthy queued reductions ahead of it; otherwise it makes no progress. This avoids processing other owners individually without spending their reserved capacity. Partial retirement retains all C and updates that position’s health key once. On reaching the requested K, that position returns to active status. The request does not change with prices. Full retirement releases C, settled lazily by its owner. `previewRetirement(positionId, acceptedPrice, demand)` on the commitment index returns a status, effective current cohort, healthy and spare commitment, queued reductions ahead, requested reduction and releasable REP. It is advisory: the caller supplies price and demand, and execution checkpoints fees first. A ready result does not guarantee progress at inclusion. New purchases can use healthy active commitments and the retained portion of healthy pending partial requests, without consuming queued reductions or clearing every request.
Purchases, redemptions and earnings	`createCompleteSet(universeId, questionId, cashAttoEth, recipient, minimumShares)` requires admission and fresh healthy capacity. Every purchase pays the configured backing-based fee, including capacity reuse, plus a prepaid resolution premium. `purchaseQuote(universeId, questionId, cash)` returns the complete fee and its premium component; `purchaseFee(cash)` returns only the backing-based part. Capacity must cover purchase cash. Ordinary holding fees continue past calendar end until reporting starts or funded units exhaust. Excess ETH is refunded after accounting and share delivery.	Redeeming complete sets reduces that question’s cash and aggregate backing demand; the purchase fee is not refunded. Released capacity can serve retiring providers without a claim for every question. Earned fees accrue through aggregate indices; the backing-based purchase fee and reporter surplus vest over the configured duration. A healthy position earns its fraction of total K, including unhealthy K in the denominator. Unassigned ETH and REP are burned. `claimEarnings` collects the owner’s ETH and REP earnings.
`SecurityPoolCapitalFeeStreams`	Only the bound capital ledger may mutate this accounting module; asset custody remains in that ledger. `addStream(ethAmount, repAmount)` funds a schedule after checkpointing, using the immutable `rewardDuration`. Equal-second additions share an endpoint; later funding appends a cumulative checkpoint. Lookup excludes released history and searches at most 48 timestamp bits, with the live range bounded by the duration. `checkpoint(eligibleThrough)` separates releases before and after the eligible cutoff.	The ledger immediately consumes `takeDeferred()`: stale ETH and REP are burned. It never restarts those amounts for future providers. `fundedOutstanding()` returns scheduled, unreleased income. Forks preserve existing dates and credit eligible frozen parent commitments when the price was fresh at the fork; unassigned parent income burns. Principal and earned claims are excluded.
`SecurityPoolPortfolioServices` and `SecurityPoolResolutionPremiumBook`	The service module owns prepaid resolution premiums. It holds no shared budget for keepers or price sponsors. Each question earns its premium only during its funded unresolved interval. A persistent expiry index removes earned units and burns the unused terminal remainder without scanning questions, because the book does not record which buyer paid it. Changes checkpoint earned income under the capital ledger’s old weights. Reporting updates replace only the affected question’s schedule. Forks copy the schedule roots and divide funded cash by chosen commitment; they do not replenish it. Before imports become operational, the fork coordinator calls `checkpointPreparationPremium(child)` to burn elapsed inactive premium and any unused terminal remainder.	The portfolio authenticates native pools, reporters and accepted price reports. The service module may credit already-earned capital fees, fund vesting streams and synchronize demand; it cannot change the accepted price or withdraw provider principal.
Personal liquidation and bounded accounting	Apart from a takeover, only the owner cures, through `setCommitment`; `takeOver(positionId, commitment, minimumAward, maximumOwnRep)` transfers a selected liability to a healthy, consenting replacement. `takeOverWithBounds` adds maximum final receiver principal and commitment, and requires the quoted receiver health target, accepted price epoch and source cohort. These bounds are checked after fee checkpointing and cure, within the same transaction. A receiver’s existing live position must belong to the source cohort; a receiver with no commitment inherits that cohort. The target’s REP funds takeover awards. No ETH deposit or execution reimbursement is required. A takeover first cures its target, and a cure pays no one. A cure removes the deficit, rounded up, so the remaining commitment is fully backed at the liquidation price. It never cuts below the owner’s new value. Removal is at least `minimumCommitmentAttoEth` unless it closes the position, never exceeds spare commitment above demand, and never leaves a queued partial reduction below that minimum. Because it removes only unhealthy commitment, it uses none of the healthy spare that retirements wait for. When spare is too small, the position stays unhealthy and eligible for takeover. Takeovers retain their time-dependent REP award, which becomes backing for the receiver’s assumed commitment. A partially taken-over private position retains every unawarded REP behind its remaining K.	Admission, fee eligibility and surplus withdrawals use `price / (1 − error)`, rounded up; cure, takeover and adverse observations use `price / (1 + error)`, rounded down, where error is the configured oracle dispute target. An owner’s health setting remains separate. Other providers’ C/K balances are unchanged by a target liquidation. Balanced trees index live commitments and health. Finality processing subtracts the previously processed prefix from the current timestamp prefix, using modular arithmetic only for historical totals; each pending deadline’s amount remains checked. `SecurityPoolFrozenHistory` appends one immutable checkpoint with constant work and resolves claims through at most 48 forest steps and 48 tree steps. Forks copy its head and the processed prefix. Work follows bounded paths and the owner’s single position, without scanning questions, providers or expired streams. Native share migration still requires one action per intervening universe.
`SecurityPoolCommitmentIndex`: liquidation accounting	Only the bound capital ledger calls `cure(id, price, multiplier, minimumCommitment, demand, target)` or `clearLiquidation(id)`. The index updates commitments and records healthy observation epochs; the ledger retains custody. Each accepted operating price stores one observation timestamp, without visiting individual owners; preparation prices do not start that history.	`liquidationStarted(id)` derives the first adverse observation after the latest healthy epoch or fresh-price recovery mutation. It returns zero for healthy or retired positions. The capital ledger exposes the same getter. No starter transaction is required; uninterrupted distress retains its original timestamp, including across stale-price deposits.
`SecurityPoolPortfolioForkCoordinator`: choices	`choose(sourceUniverse, outcome)` freezes and exports the caller’s single position and its entire deposit, including surplus collateral, into one selected branch. Idle principal without a remaining commitment and old earnings remain in the parent. Choices close eight weeks after the native fork. `startBranch(sourceUniverse, outcome)` then copies aggregate settlement and reporter roots and migrates REP once for that branch.	Choices are immutable once exported and preserve the position’s retirement cohort and requested remaining commitment. The native clock allows activation from week nine and prevents a child fork before week ten. Late preparation does not extend either phase. Parent cash is assigned as `sourceCash × chosenCommitment / sourceCommitment`, rounded down, independently of excess REP. Unselected child REP belongs to inherited outcome claims; the coordinator never chooses a branch on the owner’s behalf.
Shared branch claim recovery	`prepareBranch` deploys child capital separately from migration. `startBranch` migrates pledged REP and live recovery REP once, splits the requested child once, and assigns chosen collateral to its providers. Fresh unchosen backing may enter the branch auction; old recovery REP remains reserved for inherited claims. `finalizeBranch` creates the settlement book with assigned parent cash plus accepted auction ETH, installs funded winning commitments, and activates after the fixed deadline. Unsold REP joins claim recovery. An absent or stale price does not prevent activation; eligible holding-fee streams start only with a fresh price in an unforked child. Preparation reporting follows the fixed reporting window.	The child settlement book preserves the inherited question units. ETH redemption uses the question’s settlement units. REP has a separate Q128 entitlement accumulator and per-question corrections, so a partial claim receives its share of REP even when its ETH-unit burn rounds to zero. Finality freezes both entitlements. Live units and funded child REP are each bounded by `uint128`; cumulative REP indices use modular arithmetic across repeated forks. `attoSharesToAttoEth` and `attoSharesToAttoRep` quote the two assets through the native question pool. Recovery REP or cash below outstanding units disables new minting and ordinary holding fees. If no live claim units exist, surplus child REP is burned. Finalized source claims retain their source assets.
Source recovery eligibility and rights	`ShareToken.isPortfolioRecoveryEligible(sourceUniverse)` returns true only for a forked canonical portfolio question with live source liabilities. The settlement book’s `hasLiveForkRecoveryRight(bookId, questionId, forkTimestamp)` requires outstanding outcome supply outside frozen claims. Before sealing, a nonzero `finalAfter < forkTimestamp` excludes the question once `forkTimestamp > minimumFinalAfter`, even if finality has not yet been checkpointed. After sealing, the frozen-claim assignment is authoritative. Protected finalized shares retain ordinary source-pool redemption; transferring or consuming their recovery rights reverts with `No live source recovery right`.	`balanceOfPortfolioRecoveryRights(sourceUniverse, holder)` returns unspent Invalid, Yes and No rights, or all zeros when ineligible; their minimum bounds complete-set cash recovery. Holders combine rights using `transferPortfolioRecoveryRights(sourceUniverse, recipient, amountsAttoShares)` without transferring source shares or child migration rights. `recoverUnchosenCash(source, questionId, shares)` consumes one right per outcome for each requested share. Protected finalized claims remain in the universe where they finalized.
Reporter custody and native question materialization	`SecurityPoolReporterLedger` holds funded per-question report balances in persistent books. Only canonical games can debit their own balances. A fork charges admission to the triggering question only; unrelated report balances cannot fund it. Strictly finalized escrow remains in its source universe; live books migrate once per branch.	`SecurityPoolForker.preparePortfolioQuestion(source, targetUniverse)` creates the canonical question namespace separately from `materializePortfolioQuestion`, which installs at most one of three fixed outcome snapshots per call when needed; the question activates after the third. Bound questions do not deploy individual Collateral Repair Auctions or migrate provider vaults. Trader tokens retain their immediate-parent migration checks, so skipped native universes still need explicit token migration.
`SecurityPoolUniformPriceAuction`	Only its immutable controller starts bidding, submits funded bids, finalizes and settles refunds. Each lot contributes the same fixed ETH amount. Lower minimum REP per lot ranks first. For inventory `I`, finalization selects the largest available prefix of `F` lots, capped by target lots, whose marginal minimum `m` satisfies `F × m ≤ I`. At the target, clearing REP per lot `q = m` and sold REP is `F × q`. Below target with `F > 0`, `q = ⌊I / (F × grid)⌋ × grid` and sold REP is all `I`. With no feasible lot, the sale is zero. Bids cannot be cancelled.	Each winning lot pledges `q` REP. Any remainder `I − F × q` in a below-target sale enters the frozen bid tree as REP fee credits belonging only to winning lots. Marginal equal-price bids use cumulative proportional fills rounded to whole lots at `m`, even when `q > m`. The engine holds bid ETH; the controller holds sale REP. Refunds are pull credits for the bidder. Before finalization, `earlyRefundAttoEth` returns the full bid ETH only when strictly better-priced demand `B ≥ min(T, ⌊I / p⌋)`, where `T` is target lots and `p` is the bid’s minimum REP per lot; otherwise it returns zero. Settled, unknown and finalized bids return zero. Refunded bids remain in the tree, permanently outside every winning prefix. The same exclusion condition rejects a new bid at submission. Equal-price demand alone never makes a bid eligible. `settleAndWithdrawRefund` lets the controller credit one of a bidder’s own refund-eligible bids, unless already credited, and pay that bidder’s entire credit in one transfer; it reverts when nothing is payable, and a rejecting recipient reverts the new credit while older credit stays withdrawable. After finalization, `nextUnmaterializedBid(afterBidId)` returns the next winner still sharing fee ownership in price order. Zero starts a sweep and also marks its end. A nonzero cursor is excluded from the result and remains valid after its winner is materialized. Zero-weight subtrees skip both losing and detached bids without a history scan. Clearing, individual settlement and fee allocation use logarithmic tree paths without scanning bidders; numeric escrow and fee budgets are bounded by `uint128`.
`SecurityPoolPortfolioAuction`	The fork coordinator deploys one controller per eligible branch. Its ETH lot is `minimumCommitmentAttoEth`; target lots are the ETH shortfall divided by that lot, rounded down. Each bid escrows exactly its whole-lot bid ETH. No REP deposit or approval is required. The minimum REP per lot must cover `requiredRep(lot, openingConservativePrice, M, health)`, where `M` is `securityMultiplierBps` and `health ≥ 10,000` is the chosen target in basis points. This rounds upward after multiplying lot ETH by price and dividing by `10¹⁸`, then after applying `M / 10,000`, then `health / 10,000`. Bid minima must be positive multiples of `grid = M / gcd(M, 10,000)` and cannot exceed inventory rounded down to that grid.	There is no seller price floor or auction reserve-factor setting. Opening requires a fresh funded branch price and enough inventory to back one lot at 100% health, rounded up to the grid. At the fixed week-nine close, a missing funded quote or a conservative REP/ETH price above the opening price cancels the sale. Finalization delivers all sold REP into capital; winning commitments equal accepted bid ETH. Pledged REP and fee rights enter aggregate accounting immediately, independent of individual materialization or refunds. `settleRefund` lets anyone credit a provably excluded bid before finalization, or settle the final unfilled-lot refund afterward. Only the bidder can withdraw its credits, to a recipient of its choice, separately or combined with crediting one of its own eligible bids through `settleAndWithdrawRefund`; the combined withdrawal includes credits from the bidder’s other bids. Unsold fresh REP and all old recovery REP remain for inherited claims. Sub-lot shortfalls remain unrepaired.
`SecurityPoolAuctionVault` and `SecurityPoolCapitalAuctionDelegate`	Each bid creates a separate vault controlled by its bidder: a minimal proxy to the one implementation the auction deployer publishes, with the bidder, initial ledger, auction and bid identifier fixed in the clone’s own code and the bid identifier as its CREATE2 salt. Each clone keeps its own storage, so per-bid liability isolation is unchanged, and the implementation refuses direct use. Winning principal and commitment first share one protected capital position. `materializeAuctionBid` splits one exact funded entitlement, preserving health history and historical fees; it pays no keeper reward. The bidder’s vault materializes before its first voluntary operation and then records a permanent flag, so later operations skip the auction lookup and the ledger call; the flag only covers the initial capital ledger, child-universe ledgers after a fork keep their own checks, and it is never set for a zero fill. `depositPrincipal` pulls approved REP from the controlling wallet. `executeAndSweep` executes an owner-authorized call and returns the chosen token and ETH balance to the selected recipient.	Unmaterialized winners count toward capital, fees and fork snapshots. They cannot avoid liabilities by delaying an individual claim. A winner’s bidder cures through its vault with `setCommitment`; `takeOverAuctionBid` pays its award in the affected position’s REP. Bidding requires no ETH execution reserve. Materialization alone earns no reward. Each vault retains an independent health target, liquidation liability and future branch choice.
Portfolio module deployers	`SecurityPoolPortfolioModuleDeployers` supplies separately deployed capital, commitment-index, fee-stream, settlement-book, settlement-engine, service-accounting and reporter-ledger constructors. The fork coordinator has its own deployer. The capital, service-accounting and fork coordinator deployers share `SecurityPoolCreationCodeDeployer`; each stores its creation bytecode in two immutable, STOP-prefixed `SecurityPoolCreationCode` contracts. Each created module binds its authority to the requesting portfolio or configured controller.	Deployment permission does not grant authority over another portfolio’s modules. Canonical bindings and initialization must be verified before use. These deployment boundaries keep creation code and individual initialization transactions within EVM limits.
`EscalationGameFactory`	`deployEscalationGame` and `deployEscalationGameFromFork` have no permission check, but a successful caller must implement the `ISecurityPool` reads used during construction; an EOA or incompatible contract reverts. The `CREATE2` salt is zero; the caller is bound into the init code as the new game's `securityPool`, so each caller has one game address; the factory itself becomes the game's immutable `owner` and immediately calls `start` or `startFromFork`. Ordinary deployment requires a threshold above one attoREP and lowers a start bond at or above that threshold to `threshold - 1`. Its constructor receives separately deployed claim and deposit delegates, in that order, and requires code at both addresses. Games share these immutable helpers while keeping their own accounting through `delegatecall`. Deploying the deposit delegate separately keeps factory init code within the EVM limit. The factory has no owner role and no later `resumeFromFork` relay.	Accept a game only after `EscalationGameSet` from a recognized pool. In the supported continuation path, the owning pool calls `resumeFromFork`, which also verifies aggregate funding.
`ShareTokenFactory`	Anyone can call `deployShareToken` to deploy or retrieve a token keyed by `keccak256(abi.encode(msg.sender, salt, questionId))`. The `CREATE2` salt is the raw `salt`; the caller and question id enter through constructor arguments, and that caller is the token's initial authorized address.	Origin lineage tokens are the instances created by `SecurityPoolFactory` and named in `DeploySecurityPool`; children reuse the parent's token.
`OpenOraclePriceCoordinatorFactory`	Anyone can call `deployOpenOraclePriceCoordinator` under a caller-namespaced salt with caller-supplied OpenOracle, REP token, and positive `initialReportPriorityFeeAttoEthPerGas`; coordinator construction rejects zero and values that would consume the reserved OpenOracle `uint128` report and escalation-halt capacity. The caller therefore chooses this immutable gas-price assumption within that bound.	A pool coordinator is the instance named by canonical `DeploySecurityPool`; `SecurityPoolFactory` atomically binds it to that pool before returning, and canonical child deployment inherits the value from the parent coordinator.
`PriceCoordinatorDeploymentWorker` and `SecurityPoolDeploymentWorker`	Deployment workers split large creation code into deployable modules and bind the calling factory.	Use canonical factory registration and module bindings; code presence alone is insufficient.
`SecurityPoolDeployer` and `SecurityPoolDeploymentWorker`	Only the configured `SecurityPoolFactory` may call the deployer; only that deployer may call its worker.	They are code-size deployment plumbing. The proxy deployer deploys one deterministic `SecurityPoolOperationsDelegate`, and its address is passed into the `SecurityPoolFactory` constructor. The proxy deployer is the deterministic `CREATE2` deployment proxy that every canonical deployment goes through; it is not a Solidity source in this repository and appears in the deployment manifests as step `proxyDeployer`. The factory passes that address through its deployer and worker to every pool. Its deterministic address is published as `securityPoolOperationsDelegate`. Pools become canonical only when the factory emits `SecurityPoolRegistered` and `DeploySecurityPool`.
`EscalationGameDepositDelegate`, `EscalationGameClaimDelegate`, `SecurityPoolForkerPortfolioDelegate`, `SecurityPoolSettlementDelegate`, and `SecurityPoolOperationsDelegate`	EscalationGame delegates share game storage and implement reporting deposits and authenticated historical claims. SecurityPoolOperationsDelegate handles wallet reporting, continuation resumption, and redemption. SecurityPoolForkerPortfolioDelegate prepares child questions against shared branch state. These helpers execute in their recognized host context.	Accept resulting state and logs only when the recognized game, pool, or forker executes the matching wrapper through `delegatecall`. State changes and events then occur in that recognized contract's context. Canonical liquidation enters through the portfolio capital ledger; continuation activation enters through `SecurityPool.resumeForkedEscalationGame`.
`SecurityPoolEventEmitter`	A fixed delegate shares the question ledger storage layout and handles central fee checkpoints, surplus transfers and settlement mirrors.	Only events from canonical question addresses describe protocol state. Calling a helper directly does not mutate a registered question.
`EscalationGameProofVerifier`, `MerkleMountainRange` and `SecurityPoolUtils`	Proof and arithmetic helpers have no independent lifecycle authority.	Only an authenticated protocol transaction commits a proof or calculation to state.
`DeploymentStatusOracle`	Anyone can call `getDeploymentMask`; the constructor alone fixes the ordered address list and emits `DeploymentAddressesSet`.	It reports code presence only, not canonical wiring or readiness. Decode it using its constructor event or the matching deployment manifest order.

SecurityPoolUtils read surface

calculateInitialEscalationDepositAttoRep derives the first-report bond from theoretical REP supply. calculateMinimumVaultRepDepositAttoRep applies the configured minimum or the supply-derived default used for capital configuration. Other lifecycle and underwriting math belongs to the corresponding portfolio module.

Production contract inventory

Every production Solidity source is linked below. The preceding authority and accounting reference defines their canonical use; deploying a helper independently does not create a registered portfolio.

Area	Sources
Core and token support	`Constants.sol`, `Context.sol`, `DeploymentStatusOracle.sol`, `ERC20.sol`, `GenesisReputationToken.sol`, `IERC20.sol`, `IERC20Metadata.sol`, `IExternalGenesisReputationToken.sol`, `ReputationToken.sol`, `SafeERC20Ops.sol`, `ScalarOutcomes.sol`, `Zoltar.sol`, `ZoltarQuestionData.sol`, `GenesisUniswapV3Seeder.sol`, `PredeploymentShareSink.sol`, `TradingLiquidityToken.sol`, `TwoWayConstantProductFactory.sol`, `TwoWayConstantProductMath.sol`, `TwoWayConstantProductPair.sol`, `TwoWayConstantProductRouter.sol`, `AuthorizationSignatures.sol`, `ERC20Authorization.sol`, `IERC20Authorization.sol`
Protocol modules	`BinaryOutcomes.sol`, `DelegateCall.sol`, `DelegateCallForwarder.sol`, `EscalationClaimCheckpointTypes.sol`, `EscalationGame.sol`, `EscalationGameCalculations.sol`, `EscalationGameCarry.sol`, `EscalationGameClaimDelegate.sol`, `EscalationGameDepositDelegate.sol`, `EscalationGameEscrow.sol`, `EscalationGameProofVerifier.sol`, `EscalationGameRepCustody.sol`, `EscalationGameSettlement.sol`, `EscalationGameState.sol`, `EscalationGameStorage.sol`, `EscalationGameTypes.sol`, `MerkleMountainRange.sol`, `Multicall3.sol`, `OpenOraclePriceCoordinator.sol`, `OpenOraclePriceCoordinatorTypes.sol`, `OpenOraclePriceSource.sol`, `OpenOracleReportDelegate.sol`, `SecurityPool.sol`, `SecurityPoolAuctionVault.sol`, `SecurityPoolCapitalAuctionDelegate.sol`, `SecurityPoolCapitalFeeStreams.sol`, `SecurityPoolCapitalLedger.sol`, `SecurityPoolCapitalLifecycleDelegate.sol`, `SecurityPoolCapitalState.sol`, `SecurityPoolCommitmentIndex.sol`, `SecurityPoolCommitmentTree.sol`, `SecurityPoolCreationCode.sol`, `SecurityPoolEventEmitter.sol`, `SecurityPoolFixedAdmissionPolicy.sol`, `SecurityPoolForker.sol`, `SecurityPoolForkerPortfolioDelegate.sol`, `SecurityPoolFrozenHistory.sol`, `SecurityPoolLinearFees.sol`, `SecurityPoolMigrationProxy.sol`, `SecurityPoolOpenAdmissionPolicy.sol`, `SecurityPoolOperationsDelegate.sol`, `SecurityPoolPersistentMap.sol`, `SecurityPoolPortfolio.sol`, `SecurityPoolPortfolioAccountingDelegate.sol`, `SecurityPoolPortfolioAuction.sol`, `SecurityPoolPortfolioForkCoordinator.sol`, `SecurityPoolPortfolioModuleDeployers.sol`, `SecurityPoolPortfolioPurchase.sol`, `SecurityPoolPortfolioServices.sol`, `SecurityPoolPortfolioSettlement.sol`, `SecurityPoolReporterLedger.sol`, `SecurityPoolResolutionPremiumBook.sol`, `SecurityPoolSettlementBook.sol`, `SecurityPoolSettlementDelegate.sol`, `SecurityPoolStorage.sol`, `SecurityPoolUniformPriceAuction.sol`, `SecurityPoolUtils.sol`, `SharedPoolPriceFeed.sol`, `SharedPoolReportEscrow.sol`, `SignatureValidation.sol`, `WETH9.sol`, `ERC1155.sol`, `ShareToken.sol`, `TokenId.sol`
Factories and deployment	`Create2Deployment.sol`, `EscalationGameFactory.sol`, `OpenOraclePriceCoordinatorFactory.sol`, `SecurityPoolDeployer.sol`, `SecurityPoolFactory.sol`, `ShareTokenFactory.sol`
Interfaces	`ICapitalAccounting.sol`, `IERC1155.sol`, `IERC1155Receiver.sol`, `IERC165.sol`, `IEscalationGame.sol`, `IEscalationGameDelegateContexts.sol`, `IPortfolioServiceRoot.sol`, `IPortfolioSettlement.sol`, `IReportOperations.sol`, `ISecurityPool.sol`, `ISecurityPoolAuctionCapital.sol`, `ISecurityPoolDeploymentWorkerConfiguration.sol`, `ISecurityPoolForker.sol`, `ISecurityPoolForkerChildPoolDeployer.sol`, `ISecurityPoolPortfolioAccounting.sol`, `ISecurityPoolPortfolioNative.sol`, `ISecurityPoolQuestionAdmissionPolicy.sol`, `ISecurityPoolReporterLedger.sol`, `IShareToken.sol`, `IWeth9.sol`, `IZoltarForkState.sol`, `ITradingShareToken.sol`, `ITwoWayConstantProductFactory.sol`, `ITwoWayConstantProductPair.sol`
Oracle dependency	`OpenOracle.sol`, `ISignatureTransfer.sol`, `Errors.sol`, `IERC1363.sol`, `IERC165.sol`, `IERC20.sol`, `IERC20.sol`, `SafeERC20.sol`, `Panic.sol`, `ReentrancyGuard.sol`, `StorageSlot.sol`, `IERC165.sol`, `Math.sol`, `SafeCast.sol`

Testnet Uniswap dependencies

The UI, the bots, and the testnet deployer read Uniswap addresses from one registry, shared/core/ts/deployment/uniswapDeployments.ts.

Chain	WETH, V3 factory, QuoterV2, V4 PoolManager, V4 Quoter	SwapRouter
Sepolia (`11155111`)	Uniswap's published contracts (V3, V4); the deployer requires each to carry Uniswap's exact runtime code. An Anvil node with the Sepolia chain ID receives them by replaying Uniswap's original creation transactions, vendored byte for byte in `scripts/artifacts/uniswap-deployment.json`.	Deterministic SwapRouter (v1) bound to the published factory; Uniswap publishes none on Sepolia.
Any other testnet	Deterministic WETH plus a complete Uniswap V3 and V4 deployment from the pinned bytecode.	Deterministic SwapRouter from the pinned bytecode.