# $CLAUS: a market that people can play together

Research observed **5 October 2026**. First recommendation: test **Market Loom**, a persistent shared world whose rules are rewritten by optional, authenticated, executed trades. The boldest direction is **Liquidity Creature**, where the market remembers its path and that memory changes future executable liquidity. **Commons Crossing** is the middle candidate: people coordinate complementary trades under a collective assurance condition. These are research priorities, not chosen releases.

The interesting question is whether a programmable market can produce collective authorship, coordination or discovery worth returning for. Revenue is not required to establish that. Seven distinct directions are retained below, with reasons for deferral so a continuation need not start over.

## Public baseline and evidence limits

The public [about.json](https://claus.si/about.json) identifies Ethereum mainnet token **claus / $CLAUS**, `0x1b54E762aa34CF6E28E9C082F2848e28E45DA6b8`. Its current individual pages were read through their server-rendered `/read/Hooks/...` representations, rather than inferred from titles. The canonical `/Hooks` response is an application shell. The project says: **“Same $CLAUS. Same token address.”** No proposal here creates a replacement or second project token.

The [Funding page](https://claus.si/read/Hooks/Funding) states: **“2% project fee on the ETH value of buys and sells in the main pool.”** This divides into 1.35% wallet, 0.15% Fomo buybacks and 0.50% combined burn/liquidity. Preserve both the total and existing allocations. [Weather](https://claus.si/read/Hooks/Weather) states: **“When active, rain allocates 0.35% to burns and 0.15% to liquidity. Dry weather allocates 0.15% to burns and 0.35% to liquidity. Without a fresh signed report, each receives 0.25%.”** Signed Heathrow observations are advertised every four hours; source inspection confirms expiry is the earlier of attestation expiry and observation plus six hours. `submitWeather` pins chain, question, answer type, five members/four quorum, time bounds and signer; it rejects observations no newer than the stored one. It authenticates an IMD report, not physical weather.

The fetched [fee-state.json](https://claus.si/fee-state.json) reports block **26127666**, timestamp **2026-10-05T17:29:35Z**, fallback weather and a separate **0.30% platform fee**, for 2.30% combined. This is website-reported state, not independently reproduced chain state. Platform receipts are not project income. The separate reader pages use nearby blocks and refresh independently; their cumulative figures should not be treated as one atomic snapshot.

[Burn](https://claus.si/read/Hooks/Burn) includes direct holder burns in its supply-reduction total. [Liquidity](https://claus.si/read/Hooks/Liquidity) describes approximately $500 batches into original position 433751 and explicitly distinguishes cumulative deposits from current pool balances. [Buybacks](https://claus.si/read/Hooks/Buybacks) distinguishes Fomo deliveries from burns. [Name](https://claus.si/read/Hooks/Name) describes mutable metadata without changing balances. These are existing mechanisms, not discoveries.

[Arena](https://claus.si/read/Hooks/Arena) states: **“The game and leaderboard run on a server. The Uniswap v4 hook supplies market pulses; trading fees and their allocation are unchanged. There are no cash or token prizes.”** Included main-pool trades can pulse at most once every 12 seconds; a run accepts eight. [Journal #13](https://claus.si/read/Journal/journal%3Aclaus-arena-singleplayer-20261005) describes the existing singleplayer conversion, and [weather Journal #11](https://claus.si/read/Journal/journal%3A99e477a5-f5e0-4bc8-b3e4-4e2d516aa3a0) records the weather change. Earlier experimental direction-sensitive fees and limits in the journal are history, not current functionality.

[Journal #14](https://claus.si/read/Journal/journal%3Aimd-seat-1032-20261005) reports identity.md NFT #1032, collection `0x0000ec93127baa929e58e97dd0095a2bfb38ec1d`, in the project wallet, and explicitly says: **“The NFT is here. The worker still needs to be set up.”** Ownership was not directly read onchain. Current enrollment, uptime, assignment and earnings remain unknown. A seat is neither an oracle nor a free-request entitlement.

### What the implementation actually permits

The [Sourcify implementation response](https://sourcify.dev/server/v2/contract/1/0xFBF8A66314e1B67c9131ab320584Fe31EB34D97d?fields=all) returns an **exact match** for `FeeArenaHook`, verified at 2026-10-05T12:11:08Z. Its source and dependencies were inspected. The [proxy response](https://sourcify.dev/server/v2/contract/1/0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf?fields=all) resolves the expected implementation and provides `HookProxy` source. This is an indexed deployed-state check, not a direct RPC storage check. Publicnode was tried first; it and two alternatives returned HTTP 403. Etherscan also returned 403. No fork, fresh balances, admin ownership or current `slot0` was verified.

The proxy address mask was computed as `0x3fff`: **all 14 permissions are already encoded**. `HookProxy` authenticates its immutable canonical PoolManager before dispatching callbacks through the transparent proxy. `HookBase` supplies no-op implementations for unused callbacks. Thus additions to before/afterSwap and liquidity callbacks need not change address bits, but must preserve selectors, manager checks and existing delta behavior. This unusually permissive historical proxy is not equivalent to a minimal new hook.

`FeeArenaHook.afterInitialize` sets dynamic LP fee to zero; `beforeSwap` returns the zero override flag. Concentrating liquidity therefore does **not** currently create additional LP fee income. `_requirePool` restricts native ETH/currency0, the launch token, tick spacing, dynamic fee and this hook; a different pair or experimental pool needs a separate PoolKey and funded depth. Upgrading code cannot change the original key.

`_accrue` mints ERC-6909 native-currency claims to separate project, burn, liquidity, Fomo and platform recipients; these are liabilities/reserved allocations, not free experiment cash. `afterSwap` settles fee deltas, records Arena, buys/burns, buys for Fomo and optionally adds liquidity. A due batch checks for **900,000 remaining gas**, then permits an 800,000-gas processing call. Failed optional processing retains its funds. New designs must benchmark the entire path, including due batches, rather than quoting only a tiny new callback.

Launch, weather and Arena use unstructured namespaces, with reserve contracts holding other state. An empty ordinary Solidity storage layout is not evidence of no storage. Preserve every existing namespace, field interpretation, claim owner and immutable dependency; compare old/new snapshots and liabilities. New state needs a unique versioned namespace and explicit initialization. Rehearse the upgrade on a fork before any future release. The supplied protected tests concern new launches, including prohibitions on delegatecall: they were read but are not applicable proof for this historical proxy or a research-only deliverable. No Solidity was written or launch claimed.

Technical foundations are primary [v4 Hooks.sol](https://raw.githubusercontent.com/Uniswap/v4-core/main/src/libraries/Hooks.sol) and [PoolManager.sol](https://raw.githubusercontent.com/Uniswap/v4-core/main/src/PoolManager.sol), both source-inspected. The Uniswap concepts documentation returned 403. Sources on `main` are mutable; JSON records retrieval hashes.

## Comparison: seven retained directions

All statuses are research/proposed/deferred, never active or selected. No experiment budget has been committed.

| Stable ID | Mechanism and distinctive payoff | Status / next discriminator |
|---|---|---|
| `claus-market-loom-v1` | Executed trades compose bounded rewrites of one persistent public world; combinations unlock new actions for everyone. | Proposed; test whether collective authorship beats independent trade waves. |
| `claus-commons-crossing-v1` | Complementary signed orders execute only when a two-sided assurance condition and every limit are satisfied; successful epochs unlock a shared capability. | Proposed; compare completion, fairness and enjoyment with individual execution. |
| `claus-liquidity-creature-v1` | Price traversal changes persistent memory, which moves separately funded sponsor liquidity among habitats and changes future depth. | Proposed, ambitious; adversarial rebalance replay first. |
| `claus-trade-archaeology-v1` | A trade commits a falsifiable hypothesis; later independent evidence resolves a permanent experiment record without a wager. | Deferred: presently too much of a journal app. Revisit with an objectively resolvable market question. |
| `claus-counterfactual-reserve-v1` | Preregister two shadow inventory policies; compare executable-cost estimates, then fund a tiny live intervention separately. | Research: useful control experiment, but shadow profits cannot establish live benefit. |
| `claus-gap-commons-v1` | Auction a right to close organic same-token cross-pool gaps; escrow only realized surplus for public experiments. | Deferred: close to WTH; no verified margin or seed budget. Revisit only with measured organic opportunities and a distinct allocation mechanism. |
| `claus-market-metronome-v1` | Optional trades compose a deterministic score whose rhythm changes the next epoch's composition grammar. | Deferred: currently the Loom mechanism with a musical interface, not a separate shortlist innovation. |

[WhatTheHook](https://www.whatthehook.io/) and its [docs](https://www.whatthehook.io/docs) advertise capturing two-pool price differences and sharing positive captured profit. This is inspiration, not verified yield, audited code or demonstrated suitability for CLAUS. [Spec](https://spec.fun/) advertises a Solana extension configurator; its application bundle was fetched, but no deployed execution inspected. Extension menus do not prove Ethereum hook compatibility. Beyond these, [CoW's settlement source](https://raw.githubusercontent.com/cowprotocol/contracts/main/src/contracts/GPv2Settlement.sol) implements clearing-price order accounting, and [Dark Forest's repository](https://github.com/darkforest-eth/darkforest-v0.6) provides an onchain-world/client precedent. Neither project implements the proposals here. The assurance-contract, cellular-automaton and bounded-controller applications below are design inferences, not attributed product claims.

## Three developed concepts

### 1. Market Loom — first recommendation

**One sentence:** optional trades rewrite a shared world, and combinations of real actions unlock something that no participant could author alone.

**Example.** Alice signs “rotate tile 7” while buying 0.02 ETH of CLAUS; Bob signs “reflect tile 8” during a sell. Only successful executions count. Their transformations, with a third participant's action, form a loop that opens a bridge for all visitors, including people who never trade. The bridge changes which transformations can be composed next. This is persistent collective rule construction, materially different from Arena's independent, bounded water pulses; no score depends on traded volume.

**State and execution.** A proposed `afterSwap` extension checks both executed deltas are nonzero, validates an optional action and updates a compact board hash, epoch and bounded cell state, then emits a receipt. A 16-cell finite-state machine with at most four cells touched per action keeps work constant. `beforeSwap` retains existing fee behavior; new logic returns no additional delta. The interface renders the world and offers free exploration. No arbitrary player contract is called inside settlement. Malformed optional payloads should be ignored rather than break ordinary trades; authentication must succeed before consuming a nonce.

`sender` is a router, not Alice. Bind a signed action to chain, proxy, pool, authorized executor, direction, minimum actual executed amount, maximum amount, nonce and deadline; only a narrowly reviewed router path may relay it. A user-supplied address or `tx.origin` cannot establish authorship. Signature verification in an optional wrapper can precede the swap; the hook still needs authenticated context. Generic routes without that context remain valid trades without actions. Atomic revert must erase actions/nonces. Receipts based on actual execution prevent a free callback simulation from editing the world.

All needed callbacks exist in the actual proxy. Add one namespace; leave fee, weather and Arena state untouched. No new settlement credit/debit is needed. Test reentrancy through all existing reserve/token calls, same-transaction multi-swaps, replay, exact-output trades and partial-fill reverts. Target incremental cost **20–70k gas**, an unmeasured design target; total gas includes today's batch path. Cap payload length and forbid participant loops. Immutable rules and a bounded epoch reset limit irreversible griefing; resets alter world state, never holdings.

**Why care, money and evidence.** Holders can watch an evolving public artifact; traders can contribute deliberate actions; visitors discover rules and coordinate. There is no financial payout or prize. Traders bear market losses, 2% project plus separate platform fees, gas and possible disappointment. Development/hosting is sponsor expenditure, not net token profit. Measure voluntary repeat visitors, nontrading exploration, successfully coordinated unlocks and reported comprehension. Volume alone is not benefit; explicitly exclude self-funded churn from demand measures.

**IMD.** No runtime oracle is needed for deterministic rules. A future paid `job.open` could independently reproduce the rule transitions and test nonces/gas; a `job.continue` could review the pilot findings. Use the workflow below, not NFT ownership. IMD results require review and do not confer consensus on aesthetics.

**Objection, failure, test, smallest version.** The strongest objection is that this is an external game made expensive by trading. Bots can race desired transformations and grief the board; contract state cannot prove distinct humans. Start with a finalized-log replay and signed wrapper receipts on a local simulation, clearly **mainly an external app**. Compare it with ordinary Arena-style independent pulses in a 20–40-person play study. Predeclare success as at least half understanding the composition rule and a third returning voluntarily within a week; these are pilot thresholds, not measured results. Replay adversarial bursts and require deterministic reconstruction, bounded writes and no financial incentive to churn. The smallest version retains compositional shared state; do not reduce it to another wave effect. Move state into the hook only if shared settlement enforcement proves valuable.

Sources: C8/C12 advertised; S1/S2/U1/U2 source-inspected; P5 source-inspected README precedent; causal design is inference. All observed 2026-10-05.

### 2. Commons Crossing — collective assurance for execution

**One sentence:** willing traders make a move together only when enough complementary commitments can execute within everyone's stated limits.

**Example.** Alice wants to buy and Bob and Cara want to sell in the next ten minutes. Each signs a cancellable intent. They agree that this epoch executes only with at least one valid order on each side and a published imbalance cap. A sponsor pays bounded keeper gas. A successful epoch opens a new shared Loom action; if conditions fail, orders expire and deposited funds are reclaimable. Nobody must trade to sell later through the normal main pool.

**State and execution.** An external escrow/router stores bounded epoch commitments, spent nonces, deadline and refundable balances. In the smallest version a maximum eight-order batch executes **each trade through the existing pool**, paying its normal main-pool project/platform fee; do not cross internally and then pretend residual-only fees equal fees on every order. Simulate all fills before submission and validate actual limits atomically. The ordering policy is published and committed before execution; alternating sides is a candidate, not demonstrated fair pricing. The sponsor's payment has a hard epoch cap.

The hook's optional `afterSwap` receipts can record epoch attribution; `beforeSwap` and existing deltas stay intact. No hook upgrade is needed for a wrapper-only pilot. Later a namespace could store an authenticated epoch receipt, but ordinary swaps must never be gated on participation. A keeper triggers settlement, interfaces collect signatures, and users withdraw expired escrow outside PoolManager callbacks. Prefer signatures and user-held funds initially; if prefunding is necessary, assets equal refundable deposits plus spend authorization, with no rehypothecation. Restrict executor permissions, token approvals, cancellation races and callbacks; avoid external participant calls during swap. Bound loops at eight; no nested PoolManager unlock when already unlocked. Every currency delta must close, including native ETH and unused funds. Total batch cost is approximately the sum of constituent swaps, potentially multiple existing due-batch costs; no cheap-netting assumption.

This is not a basic limit order: its new mechanism is a **joint assurance condition and shared consequence**, with complementary participants and an explicit ordering experiment. A future uniform-price crossing contract could resemble CoW, but requires a separate fee/custody design and authorization; it is not silently included in the prototype.

**Why care, money and evidence.** Traders get a coordination experiment and the option to abandon an unbalanced epoch; observers help design collective objectives. No yield or guaranteed price improvement. Sponsors lose gas and setup cost; traders still lose to adverse price moves, fees and bad timing. No budget comes from already allocated reserves. Track execution versus independent-order counterfactuals with identical arrival times and limits, failed-epoch rate, signed-price violations, ordering dispersion and enjoyment. Compare net receipts after fees, not gross price quotes.

**IMD.** A paid `job.open` can inspect settlement/cancellation tests. Optional post-epoch chain evidence can independently check a clearly emitted executed-volume argument using `log-sum`, but cannot establish organic humans or certify fairness. Request and relay a signed result later; never block immediate exits waiting for it. One question per pilot epoch is optional overhead, not a free NFT service.

**Objection, failure, test, smallest version.** The strongest objection is that assurance adds delay and can fail in thin markets. A Sybil can supply both sides; a keeper can choose favorable ordering or withhold execution. No token reward means spoofing produces no payout. Require open competing keeper execution after a deadline, deterministic order policy, strict per-user limits, refund liveness and bounded gas. Test eight-order permutations, keeper absence, front-running cancellations and zero-amount orders; zero-amount signatures are forbidden. Reject the mechanism if the pilot lowers completion by over 20 percentage points without an offsetting declared coordination benefit. A two-party test retains the joint condition and shared unlock; an ordinary single limit order does not.

Sources: P4/S1/U2 source-inspected; I1/I2 advertised workflow; novel assurance design is inference. All observed 2026-10-05.

### 3. Liquidity Creature — boldest longer-term direction

**One sentence:** a separately funded market remembers where traders took it, and that memory changes where it offers liquidity next.

**Example.** A sponsor supplies hypothetical **$10k–$50k** of ETH and existing CLAUS to a separate experimental ETH/CLAUS pool. A bounded sequence of traversal through three price habitats “wakes” its outer habitat; at the next keeper step, up to 5% of sponsor inventory moves to a wider range. Subsequent traders face a different depth profile. Moving back does not erase the creature's memory immediately. Traders discover how a market with hysteresis responds; the interface explains its current and next possible actions.

**State and execution.** `afterSwap` records a clipped tick movement and a small memory counter, at most once per epoch; `beforeSwap` reads a precommitted habitat policy and retains transparent fees. This is a separate new hook/pool using the **same token**, with `beforeInitialize` to bind its PoolKey, before/afterSwap and any genuinely needed liquidity callbacks. Mine its own permission address; the existing proxy's all-bit permission mask does not transfer to a new hook. The existing implementation currently rejects extra pools, so simply routing a new pair through it will not work.

A sponsor vault owns only this experiment's positions. A keeper outside the triggering swap removes and adds those positions through a complete PoolManager unlock/settle sequence. Delayed rebalancing avoids recursively changing liquidity inside the current swap, and public policy changes only future depth. Target one bounded transition per hour, fixed three habitats, a 5% inventory movement cap and a global capital-loss stop. These are initial hypotheses requiring simulation. Refuse rather than execute a rebalance outside price/asset bounds; swaps keep working on last funded depth if the keeper stops. Capital can be exhausted, and thin exits remain possible even without selling restrictions.

Main pool, principal, claims, fee allocations and holder rights are untouched. Sponsor vault withdrawals must have a defined permissionless or sponsor-controlled exit according to the declared ownership; no claim token or second project token is necessary for a single-sponsor pilot. If multiple funders later contribute, ownership/accounting and losses require an additional design. Migration on the main proxy is unnecessary initially. Cross-pool arbitrage is expected and may consume sponsor value. Reentrancy guards, isolated keeper roles, no user callbacks, settled deltas and exact inventory conservation are essential. Target incremental observation **15–50k gas**, unmeasured; keeper operations can cost hundreds of thousands of gas or more.

**Why care, money and evidence.** People can discover, predict and contest a real market's memory, rather than watch a decorative pet. Holders gain an experiment around their existing asset. The sponsor owns inventory, bears adverse selection, rebalancing losses, price exposure and all first loss. There is no payout promised to players. Set experimental LP fee explicitly before any pool design; use **zero in the initial model** to avoid inventing revenue. If a future opt-in pool charges an LP fee, it is funded by that pool's traders and net of costs, not additional income from current zero-fee liquidity. Project/platform policy for the extra pool must be separately reviewed and disclosed; do not assume legacy factory policy grants it automatically.

Compare with a fixed-range sponsor position using the same initial inventory and executable external prices. Count gas, inventory marks and liquidation costs, avoid double-counting LP loss benchmarks, and measure whether nontrading visitors understand the state transition. An interesting, funded experiment may be worthwhile while losing money; state the subsidy honestly.

**IMD.** No oracle is required for deterministic market memory. An ambitious extension can use independently reproduced, pinned chain observations from another market to change a slow habitat threshold. IMD's `univ4-spot` recipe supports bounded multi-block median spot sampling, not a guaranteed manipulation-resistant fair price. Verify a v2 signed answer in the external vault, pin the question/window/consumer, cap its influence and ignore stale data. No valid answer means hold the last bounded policy, never freeze trades or sponsor withdrawals. This extension is deferred until endogenous behavior is understood.

**Objection, failure, test, smallest version.** The strongest objection is predictable rebalancing handing inventory to informed traders. Attackers can push price over a threshold, wait for the known move and reverse, effectively feeding on the creature. Per-epoch clipped movement and hysteresis reduce but do not prove safety. Replay sandwich/cycle strategies, sudden 50% price changes, depleted depth, stale data and absent keepers against the fixed-range control. Predeclare a maximum 10% experimental-capital drawdown stop and reject a policy if attackers reliably extract more than its experimental budget under realistic fees/gas. Unknown minimum manipulation capital is a decisive research question. A two-habitat, tiny separately funded local/fork pilot retains actual path-dependent depth; replacing it with a visual animation would remove the mechanism.

Sources: U1/U2/S1 source-inspected constraints; P1/P2 advertised multi-pool precedent; I1/I2 advertised oracle workflow; P5 onchain-world precedent. Novel controller and economic effects are inference, not demonstrated facts. All observed 2026-10-05.

## Costs and what IMD can actually add

These are **planning ranges**, not vendor quotes or live ETH/USD measurements. Assume engineering at $100–$200/hour and ETH at hypothetical $2,500–$4,000, gas 1–30 gwei. A 20–70k-gas increment costs roughly $0.05–$8.40; congestion can exceed this. Existing swap/batch gas, base trade fees and price impact are additional. Research prototypes need no deployed funds.

| Candidate | Setup estimate | Ongoing experiment cost | Capital / loss owner |
|---|---|---|---|
| Loom | 40–100 engineering hours: $4k–$20k; external independent review if upgrading adds $5k–$20k assumed | $20–$200/month hosting; optional IMD jobs; hook gas if later enabled | Sponsor pays setup; traders pay ordinary trading costs; no payouts |
| Crossing | 100–250 hours: $10k–$50k, plus assumed $10k–$30k custody/settlement review | $20–$200/month service; cap sponsored gas at $100–$1k/month for pilot | Users retain/refund authorized principal; sponsor covers capped keeper gas |
| Creature | 250–750 hours: $25k–$150k; assumed $20k–$75k specialist review | $100–$500/month infrastructure plus $50–$2k/month keeper gas under low/variable activity | Separate hypothetical $10k–$50k seed, fully at risk; no existing LP principal |

Independent reviews and engineering can overlap; budget them explicitly before implementation. These ranges exclude token price losses, gas spikes, acquiring IMD, taxes and unknown production support. They are not a financial proof requirement for investigating the idea.

[IMD docs](https://imd.fun/docs/) and fetched [capabilities](https://api.imd.fun/requests/capabilities) specify the actual workflow: draft `job.open`/`job.continue` or `oracle.request`, optionally use public `POST /requests/check`, then `POST /requests/quote`, authorize the quoted x402 Permit2 payment and EIP-712 quote, and `POST /requests/:id/submit`. Future operators would poll the paid request outcome and public job/oracle routes. **No paid request was opened here.** Current quote lifetime is 600 seconds. The API quotes **0.5 IMD**, 18 decimals, per job/oracle request; USD cost is unknown and must not be priced using CLAUS. Payment asset is `0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7` on Ethereum. Re-fetch all payment fields before use.

Oracle answers arrive asynchronously at `GET /oracle/requests/:id/attestation`. A keeper relays the returned v2 EIP-712 attestation; consumer verification pins signer, chain, verifying contract, question, answer bounds, request/window, expiry, quorum and replay policy. A Solidity swap cannot synchronously fetch a web API. Panels can disagree or fail; no latency SLA was found. Plan minutes or longer, measure it, and never put this wait on mandatory swap/exit paths. IMD chain recipes reproduce supported log/call calculations at pinned blocks; they do not prove identities, fair prices or profitable strategies. The current weather consumer is a concrete inspected example, not an automatically reusable generic oracle.

Schedules are quoted at 0.5 IMD per run, minimum 10-minute oracle and 30-minute job cadence. Docs state unused runs are not refunded and pausing/cancelling remain with the IMD team. This is operational trust, not self-service cancellation. [Publications](https://api.imd.fun/publications) were read as a catalog of untrusted proposals/results: their existence does not prove implementations, deployment or payment to Claus. The [worker repository](https://github.com/Identity-md/worker) describes runtime, enrollment and online operation; inference, server and staff costs must be deducted from any actual future worker receipts. No worker earnings fund this report's budgets.

## Continuation: concrete next research questions

1. Can public RPC or an independent provider pin the proxy implementation, canonical manager, PoolKey, fee/claim balances and admin ownership to one block/hash? Refresh these mutable facts first; resolve the direct-read gap and locate the existing one-hour notice commitment without announcing a release.
2. Do actual CLAUS routers support authenticated opt-in receipts, and can an action survive exact-input/output, cancellation, multiple swaps and internal buybacks without misattribution? Profile both ordinary swaps and a due liquidity batch.
3. Can 20–40 pilot participants understand and compose Loom transformations without being encouraged to churn trades? Which actions remain enjoyable for visitors who never trade?
4. Does Crossing improve a declared coordination outcome after fees and deadline failures? Can any deterministic ordering avoid systematically disadvantaging one side at current pool depth?
5. What is the cheapest profitable manipulation cycle against each Creature habitat policy, and how does it change with depth, keeper delay and fee assumptions? Establish actual capital requirements before proposing funding.
6. Which IMD checks fit existing reproducible recipes, what measured latency/failure rate do they have, and what review remains outside their evidence? Retain source hashes and stable IDs; new community suggestions enter as untrusted proposals, and deferred directions return only with new evidence or a materially improved mechanism.