저자: 똑똑한 원숭이
원래 제목: Polymarket 봇을 만들고 여러 매개변수 설정을 테스트해봤습니다. 결과는 다음과 같습니다.
작성 및 편집: BitpushNews
몇 주 전에 저는 직접 폴리마켓 봇을 만들어 보기로 했습니다. 완성 버전을 만드는 데는 몇 주가 걸렸습니다.
제가 이러한 노력을 투자하려는 이유는 폴리마켓에 실제로 효율성 허점이 존재하기 때문입니다. 일부 로봇은 이미 이러한 비효율성을 이용해 이익을 얻고 있지만, 그 규모는 아직 턱없이 부족합니다. 이 시장의 잠재력은 로봇의 수를 훨씬 능가합니다.
로봇 빌딩 로직
이 로봇의 로직은 제가 예전에 수동으로 실행했던 전략들을 자동화하여 효율성을 높인 것을 기반으로 합니다. 이 로봇은 "BTC 15분 상승/하락" 시장에서 작동합니다.
이 봇은 실시간 모니터링 프로그램을 실행하며, 현재 BTC 15분 차트로 자동 전환하고, 웹소켓을 통해 최적의 매수/매도 호가를 스트리밍하고, 고정된 터미널 UI를 표시하고, 텍스트 명령어를 통해 모든 기능을 제어할 수 있습니다.
수동 모드에서는 직접 주문을 할 수 있습니다.
미국 달러 매수 / 미국 달러 매도: 특정 금액만큼의 미국 달러를 매수합니다.
매수 주식 수 <주> 상승 / 매수 주식 수 <주> 하락: 사용자 친화적인 지정가 주문 + 취소 시까지 유효한 GTC 주문을 사용하여 현재 최고 매수 가격으로 정확한 주식 수를 매수하세요.
자동 모드는 두 구간을 반복하는 루프를 실행합니다.
첫 번째 단계는 각 라운드의 첫 번째 기간 동안의 가격 변동만 관찰하는 것입니다. 어느 한쪽 가격이 충분히 빠르게 하락하면(약 3초 이내에 movePct 이상 하락) "Leg 1"이 실행되어 급락한 쪽 가격을 매수합니다.
봇은 1단계가 완료되면 동일한 쪽을 다시 매수하지 않습니다. 2단계(즉, 헤징)를 기다리며, 다음 조건이 충족될 때만 실행됩니다: leg1EntryPrice + oppositeAsk <= sumTarget.
이 조건이 충족되면 반대쪽에서 구매를 진행합니다. 2단계가 완료되면 루프가 종료되고 로봇은 동일한 매개변수를 사용하여 다음 충돌 신호를 기다리는 관찰 모드로 돌아갑니다.
반복 도중 라운드 번호가 변경되면 로봇은 이전에 시작했던 반복을 중단하고 동일한 설정으로 다음 라운드부터 다시 시작합니다.
자동 모드 매개변수는 다음과 같이 설정됩니다: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]
주식 수: 두 거래에서 사용된 포지션 의 규모.
합계: 헤징을 허용하는 기준점.
이동(movePct): 감소 임계값(예: 0.15 = 15%).
windowMin: 각 라운드의 시작 시점부터 1단계에 허용되는 실행 시간입니다.
백테스팅
로봇의 논리는 간단합니다. 급격한 매도세를 기다렸다가 방금 하락한 쪽을 매수하고, 가격이 안정될 때까지 기다렸다가 반대쪽을 매수하여 헤지하는 것입니다. 이때 priceUP + priceDOWN < 1을 반드시 만족해야 합니다.
하지만 이러한 논리는 검증이 필요합니다. 과연 장기적으로 효과가 있을까요? 더 중요한 것은 로봇이 여러 매개변수(주식 수, 총액, 변동률, 기간 등)를 가지고 있다는 점입니다. 어떤 매개변수 조합이 최적이며 수익을 극대화할까요?
처음에는 봇을 일주일 동안 실제로 작동시켜 결과를 관찰하려고 했습니다. 하지만 이렇게 하면 시간이 너무 오래 걸리고, 한 가지 매개변수 세트만 테스트할 수 있다는 문제가 있습니다. 저는 여러 매개변수 세트를 테스트해야 하거든요.
두 번째 아이디어는 Polymarket CLOB API에서 제공하는 온라인 과거 데이터를 백테스팅에 활용하는 것이었습니다. 하지만 안타깝게도 BTC 15분 상승/하락 시장의 경우, 과거 데이터 엔드포인트에서 지속적으로 빈 데이터셋만 반환되었습니다. 과거 가격 틱 데이터가 없었기 때문에 백테스팅에서 "약 3초 이내 급락"을 감지할 수 없었고, 1단계 실행이 불가능하여 매개변수 설정과 관계없이 루프가 한 번도 발생하지 않고 투자수익률) 도 0%에 그쳤습니다.
추가 조사를 통해 다른 사용자들도 특정 시장에서 과거 데이터를 조회할 때 동일한 문제를 겪고 있음을 확인했습니다. 과거 데이터가 정상적으로 제공되는 다른 시장들을 테스트해본 결과, 해당 특정 시장에서는 과거 데이터가 제대로 저장되지 않는 것으로 결론지었습니다.
이러한 한계 때문에 이 전략을 백테스팅하는 유일하고 신뢰할 수 있는 방법은 봇이 실행되는 동안 실시간으로 최고 매수 호가를 기록하여 자체적인 과거 데이터 세트를 구축하는 것입니다.
로거는 다음 내용을 포함하는 스냅샷을 디스크에 기록합니다.
타임스탬프
둥근 민달팽이
남은 시간(초)
UP/DOWN 토큰 ID
최고 판매 가격 상/하
이어서 "기록된 백테스트" 프로세스는 이러한 스냅샷을 재생하고 동일한 자동화된 로직을 확정적으로 적용합니다. 이를 통해 폭락 및 헤지 조건을 감지하는 데 필요한 고빈도 데이터를 확보할 수 있습니다.
저는 4일 동안 총 6GB의 데이터를 수집했습니다. 더 많이 기록할 수도 있었지만, 다양한 매개변수 세트를 테스트하기에는 이 정도면 충분하다고 생각했습니다.
저는 다음과 같은 매개변수 세트를 테스트하기 시작했습니다.
초기 잔액: 1,000달러
거래당 20주
합계 목표 = 0.95
급격한 하락의 임계치는 15%입니다.
windowMin = 2분
보수적인 시나리오를 유지하기 위해 고정 금리 0.5%와 스프레드 2%를 적용했습니다.
백테스팅 결과 투자 수익률(ROI)이 86%에 달했으며, 1,000달러가 단 며칠 만에 1,869달러로 불어났습니다.
그다음에는 좀 더 공격적인 매개변수 세트를 테스트해 봤습니다.
초기 잔액: 1,000달러
거래당 20주
합계 목표 = 0.6
급격한 하락의 임계치는 1%입니다.
windowMin = 15분
결과: 투자수익률.
이는 매개변수 선택이 가장 중요한 요소임을 명확히 보여줍니다. 매개변수를 잘못 선택하면 큰 수익을 올릴 수도 있고, 막대한 손실을 입을 수도 있습니다.
백테스팅의 한계
비용과 가격 차이를 고려하더라도 백테스팅에는 여전히 한계가 있습니다.
첫째, 해당 연구는 단 며칠간의 데이터만을 사용했기 때문에 시장에 대한 포괄적인 시각을 얻기에는 충분하지 않을 수 있습니다.
이 모델은 기록된 최고 판매 가격의 스냅샷에 의존합니다. 실제로는 주문이 부분적으로 체결되거나 다른 가격으로 체결될 수 있습니다. 또한 오더북 깊이와 거래 가능량은 모델에 반영되지 않습니다.
초 단위 미만의 변동은 포착되지 않았습니다(데이터는 초당 한 번 샘플링됨). 백테스트의 타임스탬프는 1초 단위이지만, 1초 안에는 여러 가지 일이 발생할 수 있습니다.
백테스팅에서는 슬리피지가 일정하며, 가변적인 지연 시간(예: 200~1500밀리초)이나 네트워크 스파이크는 시뮬레이션하지 않습니다.
모든 거래는 "즉시" 실행되는 것으로 간주됩니다(주문 대기열이나 미결 주문 없음).
수수료는 균일하게 부과되는 것처럼 보이지만, 실제로는 시장/토큰, 주문자 및 주문 접수자, 수수료 수준 또는 조건에 따라 달라질 수 있습니다.
비관적인(신중한) 입장을 유지하기 위해 다음과 같은 규칙을 적용했습니다. 시장 마감 전에 2단계가 실행되지 않으면 1단계는 완전 손실로 간주합니다.
이는 의도적으로 보수적인 접근 방식이지만, 항상 현실을 반영하는 것은 아닙니다.
때때로 1구간이 조기에 종료될 수 있습니다.
때로는 입상권(ITM)에 진입하여 우승하기도 합니다.
때로는 손실이 완전하지 않고 부분적일 수도 있습니다.
손실 규모가 과대평가되었을 가능성은 있지만, 이는 유용한 "최악의 시나리오"를 제공합니다.
무엇보다 중요한 것은 백테스팅으로는 대규모 주문이 오더북 에 미치는 영향이나 다른 거래자 당신을 표적으로 삼도록 유도하는 행동을 시뮬레이션할 수 없다는 점입니다. 실제로는 주문이 다음과 같은 영향을 미칠 수 있습니다.
오더북 뒤흔들어라.
다른 거래자 끌어들이거나 밀어내는 것,
이로 인해 비선형적인 미끄러짐이 발생합니다.
백테스트는 사용자가 순수 유동성 클레임(가격 수용자)라고 가정하므로 아무런 영향을 미치지 않습니다.
마지막으로, 이 시스템은 속도 제한, API 오류, 주문 거부, 일시 중지, 시간 초과, 재연결 또는 로봇이 바빠서 신호를 놓치는 상황을 시뮬레이션하지 않습니다.
백테스팅은 적절한 매개변수 범위를 파악하는 데 매우 유용하지만, 실제 상황의 일부 효과는 모델링할 수 없기 때문에 100% 보장되는 것은 아닙니다.
하부 구조
호스트 컴퓨터의 리소스를 소모하지 않고 로봇을 24시간 내내 작동시키기 위해 라즈베리 파이에서 로봇을 구동할 계획입니다.
하지만 여전히 개선의 여지가 상당히 많습니다.
자바스크립트 대신 Rust를 사용하면 훨씬 뛰어난 성능과 처리 속도를 얻을 수 있습니다.
전용 Polygon RPC 노드를 실행하면 지연 시간이 더욱 줄어듭니다.
Polymarket 서버와 가까운 VPS에 배포하면 지연 시간이 크게 줄어듭니다.
제가 아직 발견하지 못한 최적화 방법들이 분명히 더 있을 겁니다. 현재 저는 웹3 개발에서 필수적인 언어가 되어가고 있는 Rust를 배우고 있습니다.
트위터: https://twitter.com/BitpushNewsCN
BitPush 텔레그램 커뮤니티 그룹: https://t.me/BitPushCommunity
Bitpush 텔레그램 채널을 구독하세요: https://t.me/bitpush
