🍎

golden-apple — 80/90 Threshold

확률 80~90% 구간의 favorite을 매수하고 90% 도달 시 매도 — 거래당 약 10% 확정 수익을 노리는 단순 threshold 전략.

유형 고확률 수렴 편승상태 운영 중 (2계정)핵심 편향 favorite-longshot bias

핵심 수식

BUY : 0.80 ≤ p < 0.90            # p = Yes/No 중 높은 쪽(favorite) 확률
      AND liquidity ≥ 50,000  AND volume ≥ 100,000  AND NOT sports
      AND condition_id당 평생 1회 (재거래 금지)
SELL: p ≥ 0.90 → 보유 전량 매도    # 유일한 청산 조건 — 손절·시간 청산·만기 처리 없음
SKIP: 매수 직전 p ≥ 0.90 → rapid_jump, 영구 제외

전략 개요

Golden Apple은 Polymarket 바이너리 예측시장에서 확률(가격)이 80% 이상 90% 미만인 outcome(Yes/No 중 높은 쪽)을 매수하고, 90% 도달 시 매도해 거래당 약 10%의 확정 수익을 노리는 단순 threshold 전략 봇이다. 핵심 가정은 두 가지 — "정보의 확산 속도로 인해 80%를 돌파한 예측은 언젠가 90%에 도달한다", "시간이 지날수록 시장 확률이 실제 사건 확률로 수렴한다".

손절(stop loss)은 의도적으로 없고, 한 번 거래(또는 급등으로 skip)한 시장은 영구히 재거래하지 않으며, 랜덤성이 큰 스포츠 시장은 전면 제외한다. Jenkins가 5분 주기로 polybot run을 실행하는 stateless one-shot 구조이고, 상태는 job별 로컬 SQLite(data/{job}/trades.db)에만 저장된다. 동일 코드베이스를 상수만 달리한 2개 Jenkins job으로 돌려 대시보드의 GOLDEN-APPLE (1), (2) 계정을 운영한다.

매수·매도 조건

매수 파이프라인 — Gamma API 전체 시장 페이지네이션(100개씩, offset 최대 5,000) 후 아래 조건을 모두 통과해야 매수한다.

조건	값 (yaml 현재값)	비고
확률 구간	0.80 ≤ p < 0.90	`outcomePrices` 중 큰 쪽(favorite) 선택. 90% 이상은 후보 제외(급등장 진입 방지)
유동성	liquidity ≥ 50,000	Gamma `liquidity` 필드. 코드 기본값 100,000
거래량	volume ≥ 100,000	Gamma `volume`(누적). 코드 기본값 0(비활성)
카테고리	스포츠 제외	tags(slug/label) + question/slug 텍스트에 `SPORTS_KEYWORDS`(약 60개) 매칭 시 제외
중복 체크	condition_id당 평생 1회	`trades` 또는 `skipped_markets`에 있으면 skip
매수 직전 재검증	CLOB midpoint 재조회	p ≥ 0.90 → `rapid_jump` 영구 제외 / p < 0.80 → 이번 사이클만 skip
최소 수량	shares = 5 USDC ÷ midpoint ≥ 5주	Polymarket 최소 주문 수량 `MIN_ORDER_SIZE=5`
주문	GTC limit BUY @ midpoint	0.01 tick 반올림, [0.01, 0.99] clamp. 응답에 `orderID`가 있으면 즉시 `HOLDING` 기록(체결 확인 없음)

매도 파이프라인 — 매수보다 먼저(Phase 1) 실행되며, 청산 조건은 단 하나다.

우선순위	조건	처리
1 (유일)	CLOB midpoint ≥ 0.90 (`sell_threshold`)	전량 midpoint limit SELL GTC → `realized_pnl = (sell - buy) × shares` 기록 후 `COMPLETED`
-	midpoint < 0.90	무조건 보유 유지. 손절·시간 기반 청산·만기 처리 로직 없음

(스캔) --[0.80≤p<0.90 & 필터 통과]--> HOLDING --[p≥0.90]--> COMPLETED
(스캔) --[매수 직전 p≥0.90]--> SKIPPED(rapid_jump, 영구 제외)
HOLDING --[p 하락/만기]--> HOLDING (영원히; redeem 로직 없음)

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

파라미터	env var	yaml 현재값	코드 기본값	의미
`buy_threshold`	`POLYBOT_BUY_THRESHOLD`	0.80	0.80	매수 최소 확률
`sell_threshold`	`POLYBOT_SELL_THRESHOLD`	0.90	0.90	매도 트리거 확률 = 매수 상한(미만)
`buy_amount_usdc`	`POLYBOT_BUY_AMOUNT`	5.0	10.0	1회 매수 금액(USDC)
`min_liquidity`	`POLYBOT_MIN_LIQUIDITY`	50,000	100,000	Gamma `liquidity` 필드 최소값($)
`min_volume`	`POLYBOT_MIN_VOLUME`	100,000	0 (비활성)	Gamma `volume`(누적) 최소값($)
`max_positions`	`POLYBOT_MAX_POSITIONS`	-1 (무제한)	-1	동시 HOLDING 수 상한
`excluded_categories`	(env 없음, yaml만)	Sports/NFL/NBA 등 10종	동일	제외 카테고리(태그+키워드)
`simulation_mode`	(CLI `--simulate`가 override)	false	false	true면 주문 미전송, `trades_sim.db` 사용
`MIN_ORDER_SIZE`	하드코딩 (trader)	-	5.0 (주)	Polymarket 최소 주문 수량
tick size	하드코딩 (clob client)	-	0.01	가격 반올림 단위, [0.01, 0.99]로 clamp

필수 credential은 POLYMARKET_PRIVATE_KEY·POLYMARKET_FUNDER_ADDRESS(없으면 즉시 종료, private key의 hex prefix는 자동 제거). SLACK_WEBHOOK_URL은 현재 매매 플로우에서 사용되지 않는다. Jenkins에서 job마다 env var만 달리 주면 같은 코드로 상이한 전략 인스턴스를 운영할 수 있다 — GOLDEN-APPLE (1)/(2)의 구현 방식.

이용하는 심리

Favorite-longshot bias의 역이용: 베팅 시장에서 대중은 longshot(저확률)을 과대평가하고 favorite(고확률)을 과소평가한다. 80~90% 구간 가격이 실제 확률보다 낮게 형성돼 있다면 favorite 매수는 양(+)의 기대값을 가진다.
정보 확산의 관성 / herding: 확률 80% 도달 = 컨센서스가 이미 한쪽으로 기울었다는 신호. 이후 뉴스 확산과 추종 매수로 컨센서스가 강화되어 90%까지 밀려 올라간다는 가정 (PRD의 핵심 가정).
해결 수렴(resolution convergence): 시간이 지날수록 시장 가격은 실제 사건 확률(대개 0 또는 1)로 수렴한다. 고확률 쪽을 들고 있으면 수렴 방향이 유리할 확률이 높다.
과잉확신을 사지 않는 안전장치: 90%를 이미 넘긴 급등 시장은 사지 않음으로써 "이미 다 오른" 뉴스에 뒤늦게 올라타는 FOMO성 진입을 배제.
스포츠 배제: 스포츠는 대중 참여가 많고 결과 랜덤성이 커서(단판 경기 분산) 위 편향들이 잘 작동하지 않는다는 판단.

강점

전략 파라미터 완전 외부화: env > yaml > 기본값 3단 병합으로 코드 수정 없이 Jenkins 레벨에서 임계값 조정 가능.
급등 방어 + 재거래 금지: [0.80, 0.90) 범위 강제와 rapid_jump 영구 skip으로 whipsaw성 반복 진입과 고점 추격을 구조적으로 차단.
매수 직전 실시간 재검증: 스캔 시점(Gamma) 가격과 별개로 CLOB midpoint를 재조회해 stale 데이터 매수를 방지.
운영 인프라 견고: 429 Retry-After 존중·5xx/연결오류 exponential backoff, Gamma 422 페이지네이션 종료 처리, tick 반올림 + clamp 등 실전에서 겪은 오류들이 코드에 반영됨.
시뮬레이션 모드의 코드 경로 동일성: 주문 전송만 mock하고 스캔~DB 기록은 동일 경로. 별도 trades_sim.db로 실거래 DB 오염 없음.
job 단위 완전 격리: DB/로그/설정이 job별로 분리되어 다계정 운영과 사후 분석(SQLite 쿼리)이 쉬움.

약점 (허점)

체결 확인이 전혀 없다 (가장 치명적): GTC limit 주문 응답에 orderID만 있으면 매수는 즉시 HOLDING, 매도는 즉시 COMPLETED. midpoint 가격 BUY limit은 best ask보다 낮아 체결되지 않은 채 열려 있을 가능성이 높고, 이 경우 DB상 포지션·realized_pnl은 허구가 된다. PENDING_BUY/PENDING_SELL·cancel_order·get_open_orders가 구현돼 있음에도 미사용.
해결(resolved)된 시장의 출구 없음: 90% 미도달 상태로 시장이 해결되면 orderbook이 사라져 매도 실패 → 영구 HOLDING. 승리 토큰의 redeem(정산 회수) 로직이 없어 이긴 포지션의 원금+수익 회수조차 수동이며 DB P&L에도 미반영.
손절 없음 = 꼬리 리스크 노출: 80%대 사건이 뒤집히면 -100%. 89%에 사서 90%에 파는 거래는 최대 이익 ~1.1%(실로그: buy 89.5% → sell 90.5% = +1.1%)인데 최대 손실은 -100%. 진입 구간 상단일수록 risk/reward 비대칭이 극단적으로 나빠진다.
스포츠 키워드 필터 오폭: "match", "game", "win the", "beat", "score" 등이 포함돼 "Will X win the 2026 election?" 같은 정치·경제 우량 후보를 소리 없이 걸러낸다 (제외 로그는 debug 레벨).
페이지네이션 상한 5,000 도달: 로그에 실제 경고 존재. offset 5,000 이후 시장은 영원히 미스캔. 서버사이드 필터를 안 써 사이클당 ~50 API 호출로 대부분을 버린다.
자본 관리 부재: max_positions=-1 + 후보 50개(로그 확인) + 사이클당 전 후보 매수 → 한 사이클에 잔고 소진 가능. USDC 잔고 조회·후보 우선순위 정렬 없음.
midpoint 기준 매매의 슬리피지 왜곡: 시뮬레이션은 midpoint 즉시 체결 가정이라 스프레드 넓은 시장에서 시뮬 P&L이 체계적으로 과대평가된다.
Gamma volume은 누적 거래량: 과거에만 활발했던 좀비 시장이 필터를 통과. volume24hr 같은 최근 활동성 지표 미사용.
미실현 손익·스냅샷 부재: total_pnl은 realized만 합산. MarketSnapshot 테이블은 정의만 있고 저장 호출이 없어 사후 검증용 시계열이 안 쌓인다.
rapid_jump 영구 제외의 기회비용: 한 번 90% 위에서 목격된 시장이 80~90 구간으로 되돌아와도 영영 진입하지 않음 — 되돌림 후 재수렴이라는 최적 시나리오를 스스로 배제.
기타: deprecated utcnow(), 주문 성공 판정이 API 응답 형태 변화에 취약, buy_probability에 재조회 가격 저장(스캔→주문 가격 변화 분석 불가), 테스트 0개.

개선 반영처

위 허점들은 신규 봇 설계에 다음과 같이 반영됐다.

golden-date — 시간 사다리: 시간 개념 없는 buy-and-hold-to-target 구조(시간 청산·만기 출구 부재, 영구 HOLDING)를 시간 사다리(time ladder) 설계로 보완.
golden-mango — 수익률 허들: "89%→90% 1% 먹기 vs -100% 리스크"의 극단적 비대칭을 최소 기대수익률 허들로 진입 단계에서 배제.
참고: 같은 골격의 sibling golden-cherry는 stop_loss/take_profit/trailing_stop/time_exit 4중 청산으로 "손절 없음" 철학과 대비되는 적극적 리스크 관리를 이미 운영 중.

A/B 검증 계획

① 시뮬레이션: --simulate로 주문 전송만 mock, 스캔~DB 기록은 실거래와 동일 경로(trades_sim.db 분리). 단, midpoint 즉시 체결 가정이라 시뮬 P&L은 과대평가 경향(약점 7)을 감안한다. ② 소액 실거래: yaml buy_amount_usdc: 5.0(USDC)으로 건당 손실을 제한. ③ 병행 비교 후 증액: 같은 코드를 env만 달리한 2개 Jenkins job(GOLDEN-APPLE (1)/(2))으로 병행 운영하고 대시보드에서 잔고·수익률을 비교한다. 판단 시 DB realized P&L은 체결 확인 부재(약점 1)로 실잔고와 어긋날 수 있으므로 지갑 잔고 기준으로 교차 확인한다.

실행 (Jenkins)

# Jenkins job × 2 (5분 cron, one-shot) — 같은 코드, env만 상이 → GOLDEN-APPLE (1)/(2)
cd ./golden-apple
export POLYMARKET_PRIVATE_KEY=<Jenkins credential>
export POLYMARKET_FUNDER_ADDRESS=<Jenkins credential>
export POLYBOT_BUY_THRESHOLD=0.80    # job별로 임계값·금액만 달리 지정
export POLYBOT_SELL_THRESHOLD=0.90
uv sync --frozen
uv run polybot run --job apple-1     # 상태는 data/{job}/trades.db 에 격리