Verbatim from KNOWN-LIMITATIONS.md at the frozen audit candidate (tag rc4-audit-candidate, aca5fcd). sha256 d29d2e87ddc7727218b56a89ff71c5186620978fcbc0ec4dfe7cae5308e34c3b. Nothing here is rounded, shortened or reworded.

GENE RC4: known limitations

Read this first. This applies to the RC4 candidate on branch rc4-candidate in ~/gene-rc4: the V6 mechanism, owner's Decision A of 2026-10-06. It is not deployed and not audited. Every number here comes from the V6 study matrices (docs/rc4/MATRIX.md, ESCALATION.md, BOUND.md), which the production code reproduces byte-identically (docs/rc4/RC3-TO-RC4.md), or from the production test suite (docs/rc4/TEST-RESULTS-RC4.md).

The owner chose security over near-spot support: "I'd rather have a weaker mechanism whose behavior we can defend than a flashy immune system that knowingly transfers value to manipulators." The limitations below are the price of that choice. They must not be hidden, softened or reframed in any UI, document or announcement.

0. The all-time-low anchor: the free permanent disable is CLOSED (V6g-D); a paid ratchet remains

Closed (V6g-D, owner-approved 2026-10-06; docs/rc4/ATL-SEMANTICS.md). Under plain V6, one sell could park the price in empty tick range. A block starting there moved atlTick to the extreme for good: free at launch, about 0.005 ETH plus 177k GENE shortly after, and every later metabolize() reverted with SafeCastOverflow.

RC4 now accepts a block start as the all-time low only when the pool has active liquidity at that price. An oversized placement is skipped (PlacementSkipped) instead of reverting metabolize(). The release tests test/grief/AtlGrief.t.sol (A, B, D, E, H) and PlacementSkip.t.sol (F, G, H) assert this.

Remaining: a liquidity-backed ratchet (paid, never profitable, not a disable). An attacker can still sell through every protocol position to one tick inside the deepest one and hold a block start there. That moves the ATL, and every later protocol buy is placed one GAP below it, so the attacker can repeat it.

What the ratchet costs and does not do:

• It costs real ETH each round: fees on both legs, plus the price impact of crossing protocol Mass.
• The attacker never profits: asserted by test/grief/AtlRatchet.t.sol.
• It never disables the protocol: metabolize, harvest and asks continue, and the protocol ends with MORE Permanent Mass than an un-ratcheted control.
• What it does do: it pushes all future protocol buying deeper below spot, so falling-market support (§1) ends up even further away.

The cost depends on market depth. It is cheap in a thin, young market and expensive in a deep one.

Plain statement: in a thin, young market a determined griefer can push all future protocol buying to a small fraction of the price for a few ETH. That is a loss of usefulness, not of funds: no value moves to the attacker, Mass keeps accumulating, and nothing is withdrawable.

Status: accepted as a known economic limitation of RC4 (owner decision, 2026-10-07). The all-time low is a truthful observation: the lowest block-start price at which the pool had active liquidity. In a sufficiently thin market, genuine trades (an attacker's, or anyone's) can move that truthful low down cheaply, because little ETH moves the price far. Every later METABOLISM bid, churn band, IMMUNITY band and REGENERATION buyback is anchored at or below it, so future protocol support can be left far below spot. Nothing in RC4 bounds this. A UI must not imply support near spot.

Why the anchor was not made persistent, and deployment not separated from the traded low. V6's safety rests on one rule: the protocol buys only at or below the lowest price that actually traded. Anyone who bought at that low (a ratchet attacker buys back there by construction) can sell into any protocol bid placed above it. Every tested way around the ratchet broke that rule and was rejected:

• Persistent or lagging anchors (V7-0..V7-6, ~/gene-rc4-study docs/rc4/RATCHET.md). These made the ratchet 60-190x more expensive, but the lag leaves the reference above the true low for up to an epoch, or indefinitely if an attacker freezes it. Pump toward the stale reference, call metabolize() first, dump into the bands: this placement sandwich was profitable and third-party funded on V7-6 (best +0.0116 ETH; protocol-assisted up to +0.164 ETH per sandwich). Production stays at exactly 0 assisted in the same 1,708 matched sandwiches.
• A separate deployment reference with a truthful ATL (V8-S, docs/rc4/V8-ACTION-LAYER.md in the study). It reproduced the same profitable sandwich (+0.0052 / +0.0079 ETH; assisted up to +0.107 ETH).
• A deployment gate that holds ETH while the truthful ATL sits far below a confirmed low (V8-A50/A25). It introduced no extraction and bounded the damage, but it was rejected by the owner: it does not restore support, and it adds a rentable suppression path (about 0.06-0.11 ETH per epoch withholds about half of METABOLISM's placements in a genuine decline).
• Conclusion: with a cheaply movable truthful low, no placement near the market is safe under the zero-protocol-assisted-extraction criterion. RC4 keeps V6g-D unchanged and documents the limitation.

1. Falling markets: no near-spot support (by design)

Every protocol buy (METABOLISM bids, the churn tier, IMMUNITY, REGENERATION's buyback) sits at or below the all-time-low block-start price. In a falling market that low is far below spot, so sellers near spot meet no protocol bids. Protocol ETH a seller can reach from spot, after 30 epochs (50 for matured markets), V6 study §7.4:

• Same totals: total ETH committed and Permanent Mass match RC3 in every organic regime. RC4 only moves where the ETH sits.
• Rising and sideways markets: identical to RC3, because the support below spot there is filled ask Mass.

2. IMMUNITY is weak in genuine sell-offs (by design)

IMMUNITY is funded only by net selling: LP_FEE of the newly funded net GENE sold, valued at the epoch's cheapest price. It is placed at or below the all-time low.

• Genuine sell-offs: RC4 places 0.3–0.8 ETH by S+7, none within 25% of spot. RC3 placed 7.7–8.9 ETH, up to 8.2 ETH within 25%.
• Low budget ceiling: a single epoch's net-sell budget can be at most about 1% x L / (4 x sqrtPrice) of the curve. Near launch that is far below the 1.5 ETH epoch cap.
• Manufactured stress buys nothing: price-restoring round trips create no IMMUNITY budget (tested).

3. REGENERATION is near-inert on the genesis curve

REGENERATION buys only within REGEN_PREMIUM_TICKS (~1%) of the all-time-low price, which is the launch price or lower. It spends at most REGEN_SHARE_BPS of the previous epoch's net-flow bid budget.

• Price limit binds first: near the all-time low the genesis curve holds only about 0.05–0.1 ETH of book per call. The 1% limit therefore binds before the 0.5 ETH call cap (test/unit/SecurityCaps.t.sol::test_G16_regenCapsBind).
• Epoch cap unreachable early: the net-flow allowance from a single epoch peaks below about 0.94 ETH on the genesis curve alone, so the 1 ETH epoch cap cannot bind until Mass deepens the book.

REGENERATION's cooldown cannot be used to lock it out (R1, 2026-10-07). Before R1, regenerate() started its 300-block cooldown before doing any work, so a call that bought nothing still blocked the keeper. Anyone could keep REGENERATION at zero for a few hundredths of an ETH per epoch (study: 0.02-0.04 ETH per 9-epoch run). Now the cooldown starts only when a call spends its whole allotment. A zero-spend call, a no-allotment call, or a dust call stopped early by the price limit leaves it untouched (test/unit/RegenCooldown.t.sol, test/grief/RegenCooldownAttack.t.sol, docs/rc4/R1-REGEN-COOLDOWN.md).

Consequence: near the genesis curve, the 1% price limit usually stops a buyback before its allotment is spent, so REGENERATION can then be called again in the same block. Every call is still bounded by the ~1% premium over the all-time low, the 0.5 ETH call cap, the 1 ETH epoch cap and the net-flow allowance. Its total spend per epoch is unchanged, and no REGENERATION sandwich was profitable.

4. Small budgets in young markets

All ETH budgets are valued at an epoch's cheapest price, so a budget never exceeds the fee its own flow paid.

• Near launch: with large price impact, 150 ETH of buys funds only about 0.23 ETH of bids.
• Where the rest goes: gross fee revenue not funded by net buying goes to the churn tier at the all-time low, so it is still committed as Permanent Mass.

5. Remaining positive "assisted" cells (not value transfers)

Across 53,929 matched V6 rows there are 0 SELFFUNDED and 0 TRANSFER cells, classified as defined in docs/rc4/MATRIX.md §1.

• Positive "assisted" cells: up to +1.03 ETH (third-party cross-epoch churn), and +116 / +14.45 ETH in the intra-block-wick families 6 and 8.
• Why they are not transfers: in every one the protocol ends above its matched counterfactual, so the attacker's extra is paid by the third-party traders the harness simulates.
• Model assumption: this rests on the harness's third-party trader model. Those churn bots are naive; in PURE rows the same attacker already makes +141.8 ETH from them. Real third parties may behave differently.

6. Coverage limits of the economic evidence

• 228 cells cannot execute: the high-wash churn cells at 5,000 and 20,000 ETH/day buy the pool's entire remaining GENE above the pinned price, failing with PriceLimitAlreadyExceeded at the minimum sqrt price. This is identical for every variant, including RC3. These cells are excluded, not counted as passes.
• No dense pump sweep: the dense 50-tick pump sweep was not run on V6. It targets RC3's floor-vs-grid aliasing, and V6 has no time floor.
• Observed bound, not a proof: the grid maxima are the largest values found, not a proof over every strategy.

7. Other limitations carried from RC3 (unchanged mechanics)

• Liveness:
• an epoch with no flow places nothing in the next epoch;
• with more than 8 pending epochs, ETH placement waits for evolve();
• the first metabolize() needs a prior evolve(), a runbook requirement.
• View staleness: epoch-dependent views show the last touched epoch until the new epoch's first touch (docs/frontend-semantics.md).
• Launcher with code is accepted on chain: check that it has no code before deployment.
• Off-chain dependencies: aggregator and route discovery need a live pool.
• No external audit yet.