원문 제목: 폴리마켓(Polymarket) 봇을 구축하고 다양한 매개변수 설정을 테스트했습니다. 결과는 여기 있습니다.

원문 작성자: @the_smart_ape, 암호화폐 연구원

번역: 비추 비트푸시 뉴스(Bitpush News)

몇 주 전, 나는 내가 소유한 폴리마켓(Polymarket) 봇을 만들기로 결심했습니다. 전체 버전은 몇 주를 소요했습니다.

나는 이러한 노력을 기울이는 이유는 폴리마켓(Polymarket)에 실제로 효율성 결함이 존재하기 때문입니다. 시장에는 이미 몇 가지 봇이 이러한 비효율성을 활용하고 있지만, 아직 충분하지 않으며, 이 시장의 기회는 여전히 봇의 수보다 훨씬 많습니다.

봇 구축 논리

이 봇의 논리는 내가 과거에 직접 수행한 전략에 기반하며, 효율성을 높이기 위해 자동화했습니다. 이 봇은 'BTC 15분 UP/DOWN' 시장에서 실행됩니다.

이 봇은 실시간 모니터링 프로그램을 실행하며, 현재 BTC 15분 순환에 자동으로 전환할 수 있으며, 웹소켓을 통해 최상의 매수/매도 가격을 이동가능하며 고정된 터미널 UI를 표시하고 텍스트 명령을 통해 완전한 제어를 허용합니다.

수동 모드에서는 직접 주문할 수 있습니다.

buy up <usd> / buy down <usd>: 특정 달러 금액을 구매합니다.

buyshares up <shares> / buyshares down <shares>: 정확한 주식 수를 구매하며 사용자 친화적인 LIMIT(지정가) + GTC(종료 전 유효) 주문을 사용하여 최상의 매도 가격에 매매됩니다.

자동 모드는 2단계 반복 루프를 실행합니다.

첫 번째 단계에서는 각 라운드가 시작된 후 windowMin 분 동안 가격 변동을 관찰합니다. 빠르게 하락하는 쪽이 있다면(약 3초 이내에 movePct 이상으로 하락), 이는 '레그 1(Leg 1)'을 트리거하고 하락쪽을 매수합니다.

Leg 1을 완료한 후 로봇은 다시 동일한 쪽을 구매하지 않습니다. 이는 "Leg 2 (헷지)"를 기다리며 다음 조건을 충족할 때만 트리거됩니다: leg1EntryPrice + oppositeAsk <= sumTarget.

이 조건을 충족하면 로봇은 반대편을 구매합니다. Leg 2를 완료한 후에는이 루프가 종료되고 로봇은 관찰 상태로 돌아가 동일한 매개 변수를 사용하여 다음 하락 신호를 기다립니다.

루프 중에 라운드가 변경되면 로봇은 해당 열린 루프를 포기하고 다음 라운드에서 동일한 설정을 사용하여 다시 시작합니다.

자동 모드의 매개변수 설정은 다음과 같습니다: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: 두 거래 단계에 사용되는 포지션 크기.

· sum: 헷지가 허용되는 임계값.

· move (movePct): 하락 임계 값 (예 : 0.15 = 15 %).

· windowMin: 각 라운드 시작을 기준으로 Leg 1을 실행하는 데 허용되는 시간.

백테스팅

로봇의 논리는 매우 간단합니다: 폭락을 기다리고, 방금 하락한 쪽을 매수 한 후 가격이 안정화되어 priceUP + priceDOWN < 1을 보장하면 반대편을 매수하여 헷지합니다.

그러나이 논리를 테스트해야합니다. 장기간에 걸쳐 실제로 효과가 있습니까? 더 중요한 것은 로봇에는 많은 매개변수 (주식 수, 총합, 이동 백분율, 창 분)가 있습니다. 어떤 매개변수 세트가 최적이며 수익을 극대화 할 수 있습니까?

첫 번째 생각은 로봇을 실시간으로 한 주간 실행하고 결과를 관찰하는 것입니다. 그러나이 방법은 시간이 오래 걸리며 한 번에 한 그룹의 매개 변수 만 테스트 할 수 있습니다. 그러나 저는 많은 그룹을 테스트해야합니다.

두 번째 아이디어는 Polymarket CLOB API에서 가져온 온라인 기록 데이터를 사용하는 것입니다. 불행하게도 BTC 15 분 상승/하락 시장의 경우 기록 된 데이터 엔드 포인트는 항상 빈 데이터 세트를 반환합니다. 기록의 발견 (ticks)이 없으면 테스트 된 폭락을 감지 할 수 없으므로 Leg 1이 트리거되지 않으며 매개변수가 무엇이든 루프가 0 번 및 투자 수익률 (ROI)이 0 %를 생성합니다.

추가 조사 결과, 다른 사용자도 일부 시장의 **시장 데이터를 검색할 때 동일한 문제에 직면했다고 합니다. 다른 시장에서 **확 actual **시장 **데이터를 return할 수있는지 테스트 한 후 이 특정 시장의 경우 **시장 **데이터가 전혀 저장되지 않았음을 확인했습니다.

이 제한 때문에이 전략을 backtest하는唯一한 신뢰할 수있는 방법은 봇이 실행되는 동안 실시간 최적 판매 가격 (**best-ask**)을 기록하여 내 **시장 데이터 세트(**history data set)를 생성하는 것입니다.

****

**Recorder**는 디스크에 스냅 샷을 기록하며 다음 내용을 포함합니다:

· **timestamp**

· 라운드 ID (**round slug**)

· 남은 초

· UP/DOWN 토큰 ID

· UP/DOWN 최적 판매 가격

그런 다음, '**기록된 백테스트**'는 이러한 스냅 샷을 replay하고 동일한 자동 로직을 결정적으로 적용합니다. 이를 통해 **flash crash**를 감지하고 자결 조건에 해당하는 고속 **데이터를 받을 수 있음이 보장됩니다.

내가 총 4일 동안 수집 한 데이터는 6GB 이었습니다. 더 많이 기록할 수 있었지만 다양한 매개 변수 집합을 테스트하는 데 충분하다고 결론지었습니다.

****

이 매개 변수 집합을 테스트하기 시작했습니다:

· 초기 잔액: $1,000

· 매 거래당 20 주식

· **sumTarget** = 0.95

· **flash crash** 임계값 = 15%

· windowMin = 2 분

나는 또한 보수적인 scenario를 유지하기 위해 고정 0.5% 수수료와 2% 스프레드를 적용했습니다.

백테스트 결과 **ROI**는 86%로, 단 몇 일 만에 $1,000이 $1,869로 변했습니다.

****

그런 다음 더 공격적인 매개 변수 집합을 테스트했습니다:

· 초기 잔액: $1,000

· 매 거래당 20 주식

· **sumTarget** = 0.6

· **flash crash** 임계값 = 1%

· windowMin = 15 분

결과: 2일 후 **투자 **수익률은 -50%입니다.

이는 매개변수 선택이 가장 중요한 요소임을 명확히 보여줍니다. 이는 많은 돈을 벌게 할 수도 있고 중대한 손실을 가져올 수도 있습니다.

백테스팅의 한계

거래비용과 스프레드를 포함하더라도 백테스팅에는 여전히 한계가 있습니다.

· 먼저, 그것은 몇 일의 데이터만 사용하며, 이는 전체적인 시장 전망을 얻는 데 충분하지 않을 수 있습니다.

· 레코드된 최상의 매도가 스냅샷에 의존합니다. 현실에서 주문은 일부만 체결되거나 다른 가격으로 체결될 수 있습니다. 또한, 주문서 깊이와 이용 가능한 거래량은 모델링되지 않았습니다.

· 밀리세컨드 이하의 작은 변동성을 캡처하지 못했습니다 (데이터는 1초마다 샘플링됨). 백테스팅은 1초의 타임스탬프를 가지고 있지만, 각각의 초 사이에는 많은 일이 일어날 수 있습니다.

· 백테스팅에서 슬리피지는 일정하며, 가변적인 지연 (예: 200-1500밀리초)이나 네트워크 피크를 모의하지 않습니다.

· 모든 거래 세션이 "즉각적인" 실행으로 간주됩니다 (주문 대기열이 없으며, 지정가 주문이 없음).

· 비용은 일관되게 부과되며, 현실에서는 시장/토큰, 주문 제출자 및 체결자, 요금 등에 따라 비용이 달라질 수 있습니다.

비관적(신중)이 유지되도록 의도적으로 한 규칙을 적용했습니다: Leg 2가 시장이 닫히기 전에 체결되지 않는 경우, Leg 1은 완전한 손실로 간주됩니다.

이것은 일부러 보수적으로 취한 조치이지만 항상 현실과 부합되는 것은 아닙니다:

· 때로는 Leg 1이 일찍 종료될 수 있습니다,

· 때로는 그것이 최종적으로 내재 가치(ITM)에 놓이고 이기기도 합니다,

· 때로는 손실이 완전한 것이 아니라 부분적일 수도 있습니다.

손실이 과대평가될 수는 있지만, 이는 실용적인 "최악의 경우" 시나리오를 제공합니다.

가장 중요한 것은, 백테스팅이 당신의 대규모 주문이 주문서에 미친 영향이나 다른 거래자들이 당신을 사냥하거나 매료시키는 행위를 모의할 수 없다는 것입니다. 현실에서는 당신의 주문이:

· 주문서를 교란시킬 수 있습니다,

· 다른 거래자들을 유인하거나 이탈시킬 수 있습니다,

· 비선형적인 슬리피지를 유발할 수 있습니다.

백테스팅은 당신이 순수한 가격 수령자(price taker)라고 가정하고 있습니다.

마지막으로, 이것은 주문 속도 제한(rate limits), API 오류, 주문 거부, 일시 중지, 시간 초과, 재연결, 또는 신호를 놓친 로봇 등을 모의하지 않습니다.

백테스팅은 좋은 매개 변수 범위를 식별하는 데 매우 가치가 있지만 100% 보장되는 것은 아니며 일부 현실 세계의 영향은 모델링할 수 없습니다.

인프라

나는 라즈베리 파이(Raspberry Pi)에서 로봇을 실행할 계획이며, 이는 내 호스트 리소스를 소비하지 않고 24/7 상시 가동을 유지하기 위한 것입니다.

그러나 여전히 betway88网页版 显著한 성능 향상余额不足:

· JavaScript 대신 Rust 사용은 더 나은 성능과 처리 시간을 제공할 것입니다.

· 전용 Polygon RPC 노드를 실행하면 지연 시간이 더욱 줄어듭니다.

· Polymarket 서버 근처 VPS에 배포하면 지연 시간이 betway88下注 更 크게 감소합니다.

분명히 아직 발견하지 못한 다른 최적화 방법들이 있을 것입니다. 현재, Web3 개발에서 필수불가欠하는 언어가 되고 있는 Rust를 배우고 있습니다.

원문 링크

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia