Verdict: the data already said no. Stop building. Pre-deployment backtest across 6 parameter sets × 119k alpha trades — every parameter set lost money after friction. We have the answer; the daemon is PAUSED as of 2026-05-25 (base-copytrade tmux down); even while it ran, no copy signal translated into a profitable round-trip in our backtest, and that backtest used the WALLET cohort that was hand-picked for upside.

Failure mode #1 — the alpha is already priced in. By the time our scanner sees a tracked wallet's swap on-chain and propagates the signal through our gates, the same swap has been seen by every other copy-trade bot on Base via the same logs. We are racing on the wrong axis (post-confirmation) when the only winning axis is pre-confirmation (mempool).

Failure mode #2 — wallet cohort selection bias. The 168 wallets were curated for past profitability; their forward profitability is much lower than backward (survivorship). Wallet-edge framework v2 stripped this to 10 "actionable" wallets — but the simulation result file (base/wallet-edge-results.json) doesn't show ANY profitable_after_friction = true.

Failure mode #3 — no contract guards. If we ever did flip live, the threat model memo (project_base_mev_protection) lists missing onlyOwner / deadline / minAmountOut guards. We'd be wide open to gas-bidding sandwiches.

Fixable? No — not as a copy-trade design. Kill the daemon. Repurpose the wallet-cohort intelligence as an INPUT to a different strategy — e.g. "if 3+ alpha wallets buy the same token in 30 minutes, fade them" (the inflow signal in our detective board). That is a real strategy; copy-trade-them-directly is not. Free the slot.