Activate edge + spread gate values (forward-test) — companion to #999

[jmoreira-valory]

Ships the Polymarket edge + spread caps as committed defaults and wires them in at runtime (companion to #999, which added the gate machinery default-OFF). The backing analysis was re-run on the live execution measure (edge_ask = p_side − best_ask, 100% coverage) and independently re-verified by 5 agents; the rationale is summarized inline below. Decision: ship as a monitored production trial (reversible, KPI-safe) — see Rollout below.

Changes

(a) The caps — polymarket_trader/service.yaml, pure caps, no floors raised

The analysis is explicit that the min_edge / spread_min floors are dead knobs; the ROI lever is the upper cap. So this PR only adds caps:

param	value	change?
strategies_kwargs.min_edge	0.01	unchanged (floor stays low — lowering it is a no-op)
strategies_kwargs.max_edge	0.15	added (cap on overconfident high-edge bets)
POLYMARKET_SPREAD_MIN	0.0	unchanged
POLYMARKET_SPREAD_MAX	0.10	added (cap — reject the widest/most illiquid books)

(b) Runtime activation — repoint the kelly_criterion strategy CID (resolves the P1 from review)

The max_edge cap is enforced inside kelly_criterion, which the agent loads at runtime by the CID in file_hash_to_strategies — not from the repo file. That map still pointed kelly_criterion at the pre-999 CID bafybeididlci… (whose strategy ignores max_edge), so the new cap was inert in deployment — a CLOB bet with edge > 0.15 would still pass. Repointed kelly_criterion → the #999 CID bafybeidme2u…:

• polymarket_trader/service.yaml — functional: activates the max_edge cap.
• trader_pearl/service.yaml (Omen) — consistency only, behaviour unchanged: Omen is FPMM, max_edge is CLOB-only and unset there, and feat(polymarket): edge-band + spread-band bet-selection gates (default no-op) #999 did not touch the FPMM edge path. This just stops Omen deploying the stale pre-999 strategy.
• aea-config.yaml (agent default) — the merged feat(polymarket): edge-band + spread-band bet-selection gates (default no-op) #999 left this stale too; now aligned.

Re-locked agent + both services; autonomy packages lock --check passes. The spread gate itself lives in the agent-package behaviour (decision_receive.py, runs from the repo), so it was already live — only the kelly strategy needed repointing. Caps remain env-overridable (STRATEGIES_KWARGS, POLYMARKET_SPREAD_MAX) for instant rollback.

Why this wasn't caught in #999 or the pre-merge smoke tests

Honest postmortem, because the gap is subtle and worth recording:

#999. It added the max_edge machinery to kelly_criterion.py and re-locked (new CID), but shipped it default-OFF (max_edge=1.0, inert) and never repointed file_hash_to_strategies. The strategy runs at runtime from the configured CID, so #999's new code — correct and fully unit-tested — was never wired into any deployment. Because the default was inert there was zero observable behaviour change, so nothing (CI, unit tests, reviewers) had a signal to expose the dangling wiring: by design, #999 changed nothing at runtime.

The local smoke tests all ran blind to it, for compounding reasons:

1. Strategy code runs from an IPFS CID, not the repo. Even make run-agent loads whatever CID file_hash_to_strategies names (the old kelly) — the new code never executed in any run.
2. The edge-reject test used the wrong knob. The forced reject used min_edge=0.99; min_edge is read by both the old and new kelly, so it rejected regardless — proving nothing about the new path. max_edge (the only discriminating knob) was never exercised with a gating value.
3. Default max_edge=1.0 is inert — a defaults-based smoke run can't engage the cap regardless of which kelly loads.
4. The Polymarket smoke run never reached the strategy — it stalled at the unrelated mech_information marketplace-enumeration step.
5. The Omen smoke "confirmation" was false. It reached a decision, but Omen is FPMM (max_edge is CLOB-only), and the max_edge=1.0 line in the BET-DECISION log is printed by the decision_receive behaviour (which does run from the repo) — not the kelly strategy (which runs from IPFS). It looked like confirmation; it wasn't.
6. 100% unit coverage tests the repo kelly_criterion.py by direct import — orthogonal to which CID the runtime loads.

Root cause / takeaway: strategy customs are deployment-decoupled from the repo — loaded by hash. A strategy-code change isn't live until its CID is (i) published to IPFS and (ii) referenced by file_hash_to_strategies; and it must be validated against the runtime strategy with a value that actually gates, not just unit-tested. This PR adds the repoint; the outstanding validation is the forward-test below.

Outstanding validation

A live forward-test (run with max_edge below the live edge and confirm the strategy rejects, reading kelly's info/rejection lines — not the behaviour's print) is still pending. It needs the new CID published to IPFS (on release) and a Polymarket run that reaches the decision (the mech_information enumeration was intermittently empty during testing). The wiring is verified by the lock; runtime gating is unit-tested.

What the analysis found

1. Edge holds on the execution measure. The gate filters p_oracle − best_ask; re-deriving on exactly that (edge_ask = p_side − fill, 100% coverage) reproduces the band — [0.05,0.10] is the best, only positive-ROI bucket (+0.6%).
2. The lever is the CAP, not the floor. Raising min_edge does nothing (ROI stays −5.4%). Capping high edge helps because high-edge bets are overconfident: the gap between p_side and realized win-rate rises monotonically to +0.52 (adverse selection, not a price artifact — independently verified).
3. Ceiling is break-even, not profit. Best gate ≈ +0.6% ROI; bootstrap CI straddles 0; one of five whole-market folds reverses −9.85pp. The mechanism is robust; the dollar effect is not statistically established.
4. Selection caveat. ~10% of bets carry negative execution edge, placed only under old configs — a forward gate never faces those.

Volume / supply (on LIVE Polymarket data)

Checked the live candidate universe (Gamma /events/keyset, ≤4-day window, + per-market CLOB book — not fleet bets): 675 markets, 294 with a 2-sided book, median live CLOB spread 0.02, ~215 pass spread ≤ 0.10 (~193 at ≤ 0.05). The spread gate is not supply-constraining. The edge cap is forecast-dependent (p_side per market), so its bet-volume effect is forward-test only. Staking KPI is unaffected — edge/spread are post-mech gates; the agent still makes every prediction, only bet volume changes.

Rollout — monitored production trial (not a validated profit claim)

This is not a "fixes ROI" change; it caps bets where the forecaster is provably overconfident, with an expected loss-reducing-to-break-even effect. Ship it as a live forward-test with a safety net:

• Baseline: trailing Polymarket capital-weighted ROI + bets/day before activation (≈ −5.4%).
• Monitor weekly: ROI, bets/day, win-rate vs baseline.
• Rollback: depends on channel — an operated deployment reverts in seconds via env (POLYMARKET_SPREAD_MAX / STRATEGIES_KWARGS), but a Pearl release reaches all end-user instances, so its rollback is a follow-up release (days). Ship to Pearl knowing the safety net is a release cycle. (Defensive change → bounded downside, so all-users is still acceptable.)
• Power note: weeks of bets catch a regression (rollback safety); confirming a positive effect needs months given the small, noisy edge — so read interim results as "not worse," not "it works."

The durable ROI fix remains upstream — calibrate the forecaster so a high p_side is actually right.

🤖 Generated with Claude Code

[dagacha]

Found one issue that prevents the new edge cap from taking effect.

[dagacha]

Re-reviewed the latest diff at 036297a. The previous max_edge wiring issue is resolved by repointing kelly_criterion to the CID that consumes max_edge, and I found no new actionable issues. LGTM.

[bennyjo]

LGTM — edge cap is now correctly wired and the spread cap was already live. One non-blocking note inline on the strategy repoint.