How-to guide
Monitor security assumptions
The contracts cannot tell you when an economic or liveness assumption has stopped holding. This guide lists, for each assumption whose truth changes with market or service conditions, what evidence to collect, how often to look, and what to do when the boundary is weak or unknown.
How to use this guide
- Before a deadline-bearing or price-sensitive action, find the rows whose assumptions the action depends on. The security model lists which assumptions protect which mechanism.
- Collect the row's evidence at the same lineage, pool, timestamp, numeraire, and decision horizon as the action, on the stated cadence, and apply the response before proceeding whenever the evidence is weak or unknown.
What to watch, how often, and what to do
| Assumptions | Operational evidence | Review cadence | Response when the boundary is weak or unknown |
|---|---|---|---|
| Executor incentives and participation — A01, A02, A03, A06 | Expected reward after gas, fees, delay, and capital lockup; number and independence of active liquidators, escalation participants, bidders, correctors, and transition executors; settle-ready OpenOracle reports, callback-recovery candidates, and overflow operations | Continuously for deadline-bearing flows; before launch and after parameter or gas-regime changes | Fund or arrange independent executors, reduce exposed value, or disclose that the affected transition may stall |
| Fork lineage value and migration readiness — A05, A07, A09, A11 | Parent and supported-child lineage value in one numeraire; observed user, custodian, exchange, interface, and proof-tool readiness to migrate assets and state within the applicable windows; documented continued-use value and secured value | Before a fork-security claim and throughout migration and coordination windows | Do not claim fork deterrence, practical migration, or value concentration; narrow supported lineage and exposure |
| REP value and liquidity versus secured exposure — A08, A13, A14 | REP supply basis, price source, depth and price impact; REP discounted-cash-flow methodology; protocol-accounted ETH collateral or explicitly broader open interest | At launch, continuously while open interest exists, and after material price, supply, liquidity, or exposure changes | Cap or stop new exposure in clients and disclosures; do not describe REP backing as economically sufficient |
| Outcome evidence and escalation funding — A04, A10 | Outcome evidence sources and availability; immediately mobilizable REP and transaction budget before each local-escalation deadline | From question creation through local resolution and any fork window | Mark the market or action impaired, surface the deadline, and avoid asserting that honest local correction remains fundable |
| Truth Auction demand — A12 | Auction demand, indicative REP/ETH depth, expected discount, and bidder operating cost | Before and during every repair auction | Disclose likely incomplete repair and plan operation of the child at only migrated collateral plus accepted auction ETH |
| Transaction inclusion and Ethereum execution — A16, A26 | Inclusion delay, base fee, priority fee, reorg depth, block gas limit, and gas schedule against each immutable window and mandatory transition | Continuously while a deadline or mandatory transition is live | Raise transaction fees where rational, use independent submission paths, and disclose missed-deadline or stranded-transition risk |
| REP/ETH price correction — A17, A18, A19 | Independent corrector availability, ownership and payoff independence, scenario-dependent wrapped Ether (WETH) and REP replacement capital, reference-market depth, manipulation cost, correction profit after fees, gas, and price impact, transaction budget, and settlement inclusion | Continuously while a report is pending or a cached price can authorize operations | Block or discourage new price-sensitive operations and disclose that an incorrect report may settle |
| Token behavior and recipient compatibility — A21, A22 | Mainnet external-token code and behavior; reviewed Sepolia genesis REP runtime bytecode, constructor allocations, and wiring; Uniswap's published Sepolia WETH runtime-code hash; WETH redeemability; burn-sink status; recipient ETH and Ethereum Request for Comments 1155 (ERC-1155) compatibility | At deployment verification and before first use of a new recipient or integration | Reject the deployment or incompatible recipient; do not rely on redirected recovery |
| Deployments, clients, data, and keys — A20, A23, A24, A27, A28 | Pinned compiler and toolchain identity; reproducible-build output, reviewed bytecode hashes, release manifest, deployed runtime code and wiring; independent reorg-aware RPC/event replay; hash and CREATE2 verification; signer, typed-data domain, nonce, witness, session, and approval inventory | At release, on every environment or account change, and continuously for indexers | Stop signing or operating, reject an unverifiable deployment, revoke compromised authority where possible, and re-establish canonical state from independent sources |
| Question selection — A15 | Immutable question ID and metadata, evidence plan, and pool relevance | Before pool selection | Reject or warn on the selection; do not represent an admitted question as relevant or resolvable |
| Immutable parameters — A25 | Deployed immutable values and every documented economic, timing, integer-width, and gas relationship | Before deployment and after any change in external gas or market conditions used by the model | Treat the immutable deployment as unsupported; there is no administrative parameter repair |