golden-cherry — Resolution Momentum

핵심 수식

BUY : 0.75 ≤ p ≤ 0.92 (양끝 포함)  AND  24h ≤ (endDate - now) ≤ 720h
      AND liquidity ≥ 10,000  AND  condition_id당 평생 1회

SELL (우선순위 순, 매 사이클 midpoint 검사):
  ① P&L ≤ -8%  (stop_loss)        ② P&L ≥ +10%  (take_profit)
  ③ 현재가 < 최고가 × 0.95 (trailing_stop)   ④ 해결 12h 전 (time_exit)

전략 개요

Golden Cherry는 "해결(resolution)이 가까워진 고확률 favorite은 1.0으로 수렴한다"는 가정에 베팅하는 봇이다. Gamma API로 유동성 있는 활성 시장을 전수 스캔해서, 확률이 75~92% 구간(config 기준)이고 해결까지 24h~720h(1~30일) 남은 시장의 favorite 토큰을 시장당 1회, 고정 금액(USDC)으로 매수한다. 이후 Jenkins가 3~5분마다 봇을 재실행할 때마다 보유 포지션의 midpoint를 조회해 손절(-8%) → 익절(+10%) → 트레일링 스탑(최고점 대비 -5%) → 시간 청산(해결 12h 전) 순으로 청산 조건을 검사한다. 핵심 수익 원천은 "매수가 0.75~0.92 → 해결 직전 0.95~0.99 매도"의 수렴 구간 캡처이며, 한 번 거래(또는 skip)한 시장은 영구히 재진입하지 않는다.

원래 PRD는 "80% 매수 → 90% 매도" 단순 전략이었고, 이후 모멘텀(골든크로스) 전략을 거쳐 현재의 Resolution Momentum(시간 기반 진입 + 4중 청산)으로 정착했다.

매수·매도 조건

매수 — 스캔 조건 (아래를 모두 통과해야 후보):

매수 — 실행 재검증 (후보별):

사이징: buy_amount_usdc는 USDC 달러 단위. 주수 = 금액 ÷ 가격 — 예: $5 @ 0.80 → 6.25주. 가격 0.92에서는 5주 최소요건 때문에 최소 $4.6 필요.

매도 (매 사이클 보유 포지션 전수 검사. midpoint 조회 → max_price 갱신 → P&L = (현재가-매수가)/매수가):

매도 = 현재 midpoint에 지정가 GTC SELL(보유 주수 전량). 성공 판정 즉시 COMPLETED + realized_pnl = (매도가-매수가)×주수 기록, 월별 CSV(data/{job}/trades_YYYY-MM.csv) append.

중요한 상호작용: max_price가 매수가로 초기화되므로, 가격이 오르지 못하면 트레일링 -5%가 손절 -8%보다 먼저 발동한다. 즉 실효 손절선은 -5%이고, -8% 손절은 한 사이클(3~5분) 사이 3%p 이상 갭 하락할 때만 작동하는 백업이다. 또 TP +10%는 매수가 ≤ 0.909일 때만 도달 가능(가격 상한 1.0) — 0.91~0.92 진입 건은 익절 불가, 트레일링/시간 청산으로만 나간다. 실제 수익의 본류는 "수렴 후 해결 12h 전 time_exit으로 0.95+ 매도"다.

--yes-only와 side 선택: 기본 모드는 Yes/No 중 높은 쪽을 favorite으로 선택해 NO 토큰도 매수한다(longshot 시장의 No @ 0.9 등, 로그에서 다수 확인). --yes-only(Jenkins 운영 모드)는 항상 index 0 토큰만 반환 → NO 토큰은 절대 매수 불가, Yes 확률 75% 미만 시장(= No가 favorite)은 확률 필터에서 탈락. negRisk 다후보 이벤트에서는 "1위 후보만 산다"는 의미가 된다. 주의: CLI --yes-only는 켜기만 가능(끄려면 플래그 생략 + env/yaml false), --simulate도 동일 구조.

파라미터 총표 (우선순위: env > config.yaml > 코드 기본값)

로그(2026-05-20) 기준 실제 운영 인스턴스는 env override로 85%~95% / 유동성 $20k / buy $2,000 조합도 사용된 적이 있다. yaml은 baseline일 뿐, Jenkins env가 실제 운영값이다. 필수 credential은 POLYMARKET_PRIVATE_KEY·POLYMARKET_FUNDER_ADDRESS(없으면 즉시 종료, private key의 hex prefix는 자동 제거).

이용하는 심리

• Favorite-Longshot Bias: 예측시장 참가자는 복권성 longshot을 과대평가하고 favorite을 과소평가하는 경향이 있다. 75~92% 구간의 favorite은 실제 실현 확률 대비 저평가되어 있어, favorite 매수는 구조적 +EV라는 가정.
• 해결 직전 수렴 (정보 확실성 증가): 해결이 가까워질수록 불확실성이 사라지며 가격이 0 또는 1로 수렴한다. 전략 문서는 Dune Analytics 데이터(24h 전 정확도 88.6% → 4h 전 94.2%)를 근거로 인용. 봇은 이 마지막 수렴 구간(0.8 → 0.98)의 "시간가치 소멸"을 산다.
• 관성/앵커링: 이미 방향이 정해진 이벤트도 대중은 마지막까지 극단가(0.99) 매수를 주저하므로 0.9 부근에 유동성이 남는다. 봇은 그 잔여 스프레드를 기계적으로 수취한다.
• 해결 리스크 회피 프리미엄: 해결 직전 보유는 "혹시나" 리스크가 있어 대중이 프리미엄을 요구한다. 봇은 12h 전 time_exit으로 그 리스크를 다음 사람에게 넘기면서 수렴분만 취한다.

강점

• 단순하고 검증 가능한 상태 머신: 스캔 → 매수 → 4중 청산. 사이클당 1회 실행이라 Jenkins 장애 시에도 상태가 DB에 남는다.
• 수렴 구간 캡처 구조가 실제로 돈이 되는 설계: TP에 안 걸려도 time_exit이 해결 12h 전 0.95+에서 강제로 이익을 실현시켜, favorite 승리 시 8~20% 구간 수익을 체계적으로 회수한다.
• rapid_jump skip: 스캔~주문 사이 급등한 시장을 사지 않고 영구 제외 — "계단식 급변 시 아무것도 안 한다"는 PRD 요구를 그대로 구현.
• 운영 편의: env>yaml>기본값 3단 설정, job별 DB/로그 분리, 월별 CSV, HTML 리포트, 페이지네이션 422 정상 종료, 429/5xx 백오프 등 운영 디테일이 좋다.
• 중복 진입 방지가 DB unique + skip 테이블로 견고하다 (동일 job 내에서는).

약점 (허점)

• 체결 확인 없음 (가장 큰 회계 허점): 지정가 GTC 주문을 midpoint에 내고 orderID만 받으면 즉시 HOLDING/COMPLETED로 기록. 미체결·부분체결이면 DB와 지갑이 영구히 어긋난다. 미체결 주문 취소/재시도 로직도 없음.
• midpoint 기준 P&L 과대평가: 실제 매수는 ask, 매도는 bid 근처 체결인데 봇은 mid로 사고 mid로 판 것으로 기록. 스프레드 2틱이면 $5 포지션에서 왕복 ~2-4%가 허수.
• 해결된 시장 처리 부재: 보유 중 시장이 endDate보다 먼저 해결되면 orderbook 404 → 매 사이클 매도 실패 → 영구 HOLDING 좀비 포지션 (2026-05-20 로그에서 실제 발생). redeem·패배 확정 시 realized_pnl 반영도 없어 총 P&L 통계가 실제와 어긋나는 주원인.
• 트레일링 스탑이 손절을 사실상 대체: 실효 손절선 -5%. 75~85% 구간 favorite의 일상 노이즈(±3~5%p)에 whipsaw로 털리기 쉽고, -8% 손절 파라미터는 장식에 가깝다.
• rapid_jump 영구 밴의 부작용: 한 번이라도 sell_threshold를 넘으면 영구 skip — 이후 가격이 구간으로 되돌아와도 기회를 영영 잃는다 (30일 진입창에서는 과도하게 보수적).
• endDate 신뢰성: Gamma endDate는 실제 해결 시각이 아니라 마감 예정일인 경우가 많다. 조기 해결이면 time_exit 발동 기회 자체가 없고, 늦은 해결이면 12h 전 청산이 무의미하게 일찍 나간다. no_end_date 시장은 전부 배제.
• 노출 관리 없음: max_positions=-1 + 고정 금액 → 후보 100개면 100건 매수. 이벤트 상관관계 제어가 없어 같은 선거의 "A 당선 Yes"와 "B 당선 No"를 동시 매수(2026-05-20 로그의 Texas primary 사례)해 동일 리스크를 2배로 진다.
• job 간 중복 매수: 중복 방지가 job DB 단위라 같은 지갑으로 다른 job을 돌리면 같은 시장을 이중 매수한다.
• time_based.enabled=false면 매수 crash: 매수 로그 f-string이 None에 .1f 포맷을 적용해 TypeError → 사이클 전체 실패. 확률-only 모드는 현재 코드로 동작 불가.
• 스키마 마이그레이션 부재: 컬럼 추가 시마다 수동 DB 조치 필요 (2026-02-04 로그에 no such column: trades.max_price 사이클 실패 기록).
• yes-only의 기회 손실: No가 favorite인 시장(Yes 8% / No 92%)은 진입 불가. 로그 기준 후보의 과반이 No side — 의도된 트레이드오프이나 진입 유니버스를 크게 줄인다.
• config·README·문서 간 드리프트: README는 4~24h 창, 실제 yaml은 24~720h, 로그의 실운영은 85~95%로 제각각. 30일 창은 사실상 "시간 필터 있는 favorite 매수"다.
• 스포츠 필터 비활성: PRD는 스포츠 제외가 명시 요구였으나 현재 excluded_categories: []로 완전 꺼져 있고, 실제 NHL/월드컵/테니스 시장을 스캔·매수 중 (2026-05-20 로그: French Open No 매수).
• 알림 부재: SlackNotifier 미연결 — 주문 실패·좀비 포지션·사이클 crash가 로그 파일에만 남는다.
• tick size 하드코딩(0.01): 0.001 tick 시장에서 반올림이 과도해 유리한 가격을 버리고, clamp 상한 0.99로 고가 매도 시 1틱 손해 가능.

개선 반영처

• golden-date — 허점 5개 수정: cherry에서 확인된 허점 5개를 수정해 설계된 후속 봇(시간 사다리 기반). cherry의 회계·청산 허점이 date의 설계 요구사항으로 직결됐다.

A/B 검증 계획

① 시뮬레이션: --simulate / yaml simulation_mode / scripts/simulate.py 3경로. DB가 trades_sim.db로 분리되고 주문만 가짜 성공(SIM_BUY_xxxx)으로 리턴하되, 가격 조회(midpoint)는 실제 API를 사용하므로 시뮬레이션에도 실키(.env)가 필요하다. ② 소액 실거래: yaml buy_amount_usdc: 5.0. ③ 파라미터 변형 후 증액: Jenkins env override로 변형 운영(실로그 기준 85~95% / 유동성 $20k / 건당 $2,000 조합 이력). 판단 기준: 월별 CSV에 쌓이는 hours_until_resolution_at_buy·entry_reason으로 잔여시간 버킷별(24-72h / 72-240h / 240-720h) 승률·수익을 집계해 진입창의 우열을 데이터로 검증한다.

실행 (Jenkins)

# Jenkins cron (3~5분 주기, one-shot — 봇 내부 루프 없음)
cd ./golden-cherry
export POLYMARKET_PRIVATE_KEY=<Jenkins credential>
export POLYMARKET_FUNDER_ADDRESS=<Jenkins credential>
uv sync --frozen
uv run polybot run --yes-only        # 운영 모드: Yes(index 0) 토큰만 매수
# 상태는 data/{job}/trades.db, 월별 CSV는 data/{job}/trades_YYYY-MM.csv