Levandor

crypto-5m-algo Both-Sides Decision (2026-06-27)

5 min read

Decision + plan pointer (2026-06-27): the crypto producer graduates from a single UP-only latency-test source to a real both-sides strategy — enable the DOWN side and split the one pmv2 source into crypto_5m_algo_up + crypto_5m_algo_down so PM can arm/cap each direction independently. PLAN + cross-team coordination done; code NOT yet implemented.

For Agents

Two coupled changes, pmv2-sources scope only: (1) EMIT_BOTH_SIDES=true — fire DOWN on p_cal<=0.20 and buy the Down-token book ask (NOT the synthetic complement); (2) split source crypto_shortterm_latency_test → crypto_5m_algo_up + crypto_5m_algo_down. Subjects derive 100% from order.source (pmv2.order.<source>.entry) — no subject literals in our code. Single-fire-per-window preserved (a window fires Up XOR Down). Calibration reused unchanged. PM is outcome-agnostic (no PM code). Plan in repo at docs/superpowers/plans/2026-06-27-crypto-5m-algo-both-sides.md (commit d61983b).

Decision

1. Enable the DOWN trade side (EMIT_BOTH_SIDES=true). v1 was UP-only by design (only the Up-token book was polled). The validated edge is symmetric (regime |p_cal-0.5|>=0.30), so the DOWN half is real money left on the table. DOWN = p_cal<=0.20 → buy the Down token at the Down-token book ask — the actual Down order-book’s ask, NOT the synthetic complement (1 - Up_ask). This is the correctness crux: the deferred-upgrade note in crypto-shortterm-handover-2026-06-26 already flagged “poll the Down-token book, NOT the synthetic complement.”

2. Split the single source into two. crypto_shortterm_latency_test → crypto_5m_algo_up + crypto_5m_algo_down. Two sources = two subjects = two pmv2_autotrade_sources rows, so PM can dry/live-arm and daily-cap each direction independently (you can run UP live while DOWN stays dry, and cap them separately).

Scope — sources/subjects ONLY

Not a rebrand

This touches pmv2 sources + subjects only. Explicitly OUT of scope: the Supabase schema stays crypto_shortterm; the systemd services stay shortterm-crypto-algo-*; the repo stays pmv2-crypto-algo. A full rename is deliberately deferred — do not widen the blast radius.

Why it’s safe — what is reused unchanged

  • Calibration reused as-is. The frozen 20-bin calibration.json already covers the Down-conviction bins (thousands of samples). No re-fit, no gate re-run — the symmetric regime is what the offline analysis already validated.
  • No subject literals in our code. Subjects derive 100% from order.source (pmv2.order.<source>.entry); adding two sources automatically yields the two new subjects. Nothing hard-codes a subject string.
  • Single-fire-per-window preserved. A window fires Up XOR Down, never both. emitted_signals keeps window_id as its key and gains a source column to record which side fired.
  • PM is outcome-agnostic — zero PM code. @positionmanager buys whatever token_id the EntryOrder carries; the Down token is just another token_id. The only PM-side change is data: two new pmv2_autotrade_sources rows. No executor code.

Structural work (the actual code change)

  • Thread a side through the pipeline: feed → engine → Observation → emit. The fire logic mirrors UP for the DOWN conviction bucket.
  • Poll BOTH token books (Up-token + Down-token), not just the Up book — needed so DOWN prices against its own real ask.
  • Record the Down book. Migration 0006 adds 6 down-book observation columns + the emitted_signals.source column.
  • 8 code tasks, TDD. Plus cross-team coordination and a staged dry→live rollout (Approach A: live-validated).

Plan

docs/superpowers/plans/2026-06-27-crypto-5m-algo-both-sides.md in the pmv2-crypto-algo repo (commit d61983b). 8 TDD code tasks + coordination + staged dry→live (Approach A, live-validated).

Coordination (babylon, 2026-06-27)

  • @deploy — DM #819: add NKey permits for the two new subjects (pmv2.order.crypto_5m_algo_up.> / …down.>) — can proceed in parallel; then apply migration 0006 + redeploy emit at the code pin; finally retire the old crypto_shortterm_latency_test permit.
  • @positionmanager — DM #820: create two dry pmv2_autotrade_sources rows (crypto_5m_algo_up / crypto_5m_algo_down, $100 cap each proposed); confirm the pmv2.order.> stream wildcard already captures the new subjects; confirm the outcome-agnostic Down handling (buys our token_id as-is); retire the old source.
  • pmv2 channel: awareness post #821.

Status

PLAN + coordination done — code NOT yet implemented

The decision is made, the plan is committed (d61983b), and the three coordination messages are sent. No producer code is written yet. The dry→live arm stays Andras’s explicit per-side switch (PM resolves min(global, source) — live needs both global and the per-side source flipped; see crypto-shortterm-handover-2026-06-26).

Update (2026-06-28) — implementation underway

Code now exists on branch feat/down-side (3 commits, whole-workspace gates green; NOT pushed/deployed, no live-DB writes). The post-review money-path fix pass — incl. the persist-before-publish dedup invariant, the BookView refactor that closes the “Down-reads-UP-book” bug class, and the select_side/migration-0006 fail-fast work — is documented in crypto-shortterm-down-side-money-path-fixes-2026-06-28.

Graph View

Backlinks