Tác giả: Chú khỉ thông minh
Tiêu đề gốc: Tôi đã xây dựng một bot Polymarket và thử nghiệm nhiều thiết lập tham số khác nhau, đây là kết quả.
Biên soạn và chỉnh sửa bởi: BitpushNews
Vài tuần trước, tôi quyết định tự xây dựng một bot Polymarket của riêng mình. Phiên bản đầy đủ đã mất của tôi vài tuần để hoàn thành.
Tôi sẵn sàng đầu tư công sức này vì thực sự có những lỗ hổng về hiệu quả trong Polymarket. Mặc dù một số robot đã kiếm được lợi nhuận từ những điểm không hiệu quả này, nhưng vẫn chưa đủ. Cơ hội trong thị trường này vẫn lớn hơn nhiều so với số lượng robot hiện có.
Logic xây dựng robot
Logic của robot dựa trên một tập hợp các chiến lược mà tôi từng thực hiện thủ công, và tôi đã tự động hóa chúng để nâng cao hiệu quả. Robot hoạt động trên thị trường "BTC 15 phút TĂNG/GIẢM".
Bot này chạy một chương trình giám sát thời gian thực có thể tự động chuyển sang lần BTC 15 phút hiện tại, truyền phát giá mua/bán tốt nhất qua WebSocket, hiển thị giao diện người dùng cố định và cho phép điều khiển hoàn toàn thông qua các lệnh văn bản.
Ở chế độ thủ công, bạn có thể đặt lệnh trực tiếp.
Mua lên <usd> / mua xuống <usd>: Mua vào một lượng đô la Mỹ cụ thể.
buyshares up <shares> / buyshares down <shares>: Mua chính xác số lượng cổ phiếu bằng lệnh LIMIT + GTC (có hiệu lực cho đến khi hủy) dễ sử dụng, được thực hiện ở giá chào bán tốt nhất hiện tại.
Chế độ tự động chạy một vòng lặp hai bước lặp đi lặp lại.
Bước đầu tiên là chỉ quan sát biến động giá trong khung thời gian đầu tiên của mỗi vòng. Nếu một trong hai phía giảm đủ nhanh (với mức giảm ít nhất là movePct trong khoảng 3 giây), nó sẽ kích hoạt "Vòng 1", mua vào phía đã giảm mạnh.
Sau khi hoàn thành Giai đoạn 1, bot sẽ không bao giờ mua cùng một phía nữa. Nó sẽ chờ "Giai đoạn 2 (tức là phòng ngừa rủi ro)" và chỉ kích hoạt nếu điều kiện sau được đáp ứng: Giá vào lệnh giai đoạn 1 + Giá chào bán đối diện <= Tổng mục tiêu.
Khi điều kiện này được đáp ứng, nó sẽ mua hàng ở phía đối diện. Sau khi hoàn thành Chặng 2, vòng lặp kết thúc và robot quay trở lại chế độ quan sát, chờ tín hiệu va chạm tiếp theo bằng cách sử dụng cùng các thông số.
Nếu lần vòng thay đổi trong quá trình thực hiện, robot sẽ bỏ qua vòng vừa mở và bắt đầu lại ở vòng tiếp theo với cùng các thiết lập.
Các tham số chế độ tự động được thiết lập như sau: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]
Số lượng cổ phiếu: Quy mô vị thế được sử dụng trong hai giao dịch.
Tổng: Ngưỡng cho phép phòng ngừa rủi ro.
move (movePct): ngưỡng giảm (ví dụ: 0,15 = 15%).
windowMin: Thời gian thực thi cho phép đối với Chặng 1, bắt đầu từ đầu mỗi vòng.
Kiểm thử ngược
Logic của robot rất đơn giản: chờ đợi đợt bán tháo mạnh, mua vào phía vừa giảm giá, sau đó chờ giá ổn định và phòng ngừa rủi ro bằng cách mua vào phía ngược lại, đồng thời đảm bảo rằng: priceUP + priceDOWN < 1.
Tuy nhiên, logic này cần được kiểm chứng. Liệu nó có thực sự hiệu quả về lâu dài? Quan trọng hơn, robot có nhiều tham số (số lượng cổ phiếu, tổng số, tỷ lệ di chuyển, thời gian cửa sổ, v.v.). Bộ tham số nào là tối ưu và tối đa hóa lợi nhuận?
Ý tưởng ban đầu của tôi là cho bot chạy trực tiếp trong một tuần và quan sát kết quả. Vấn đề là việc này mất quá nhiều thời gian và chỉ có thể kiểm tra một bộ thông số, trong khi tôi cần kiểm tra nhiều bộ thông số khác nhau.
Ý tưởng thứ hai của tôi là sử dụng dữ liệu lịch sử trực tuyến từ API CLOB của Polymarket để kiểm thử ngược. Thật không may, đối với thị trường BTC tăng/giảm trong 15 phút, điểm cuối dữ liệu lịch sử luôn trả về một dữ liệu trống. Không có dữ liệu giá lịch sử, việc kiểm thử ngược không thể phát hiện ra "sự giảm mạnh trong khoảng 3 giây", không thể kích hoạt Chặng 1, và dẫn đến lần vòng lặp và lợi tức đầu tư (ROI) 0% bất kể các tham số được thiết lập.
Sau khi điều tra thêm, tôi phát hiện ra rằng những người dùng khác cũng gặp phải vấn đề tương tự khi truy xuất dữ liệu lịch sử từ một số thị trường nhất định. Tôi đã thử nghiệm với các thị trường khác và thấy chúng thực sự trả về dữ liệu lịch sử , và kết luận rằng, đối với thị trường cụ thể này, dữ liệu lịch sử đơn giản là không được lưu giữ.
Do hạn chế này, phương pháp duy nhất đáng tin cậy để kiểm tra lại chiến lược này là tạo ra dữ liệu lịch sử của riêng tôi trong khi bot đang chạy bằng cách ghi lại giá chào bán tốt nhất trong thời gian thực.
Trình ghi nhật ký ghi một bản chụp nhanh vào ổ đĩa, bao gồm các thông tin sau:
Dấu thời gian
Viên đạn lần
Những giây còn lại
ID Token UP/DOWN
Tăng/Giảm Giá Bán Tốt Nhất
Tiếp theo, quy trình "kiểm thử ngược ghi lại" sẽ phát lại các ảnh chụp nhanh này và áp dụng một cách xác định cùng một logic tự động. Điều này đảm bảo rằng dữ liệu tần suất cao cần thiết để phát hiện các sự cố và điều kiện phòng ngừa rủi ro luôn sẵn có.
Tôi đã thu thập tổng cộng 6 GB dữ liệu trong 4 ngày. Tôi có thể thu thập nhiều hơn, nhưng tôi cho rằng như vậy là đủ để thử nghiệm các bộ thông số khác nhau.
Tôi bắt đầu thử nghiệm bộ thông số này:
Số dư ban đầu: 1.000 đô la
20 cổ phiếu lần giao dịch
sumTarget = 0.95
Ngưỡng giảm mạnh là 15%.
windowMin = 2 phút
Tôi cũng áp dụng mức lãi suất cố định 0,5% và biên độ chênh lệch 2% để đảm bảo tính thận trọng.
Kiểm tra lại chiến lược đầu tư cho thấy tỷ suất lợi nhuận đầu tư (ROI) là 86%, và 1.000 đô la đã biến thành 1.869 đô la chỉ trong vài ngày.
Sau đó, tôi đã thử nghiệm với một bộ thông số mạnh mẽ hơn:
Số dư ban đầu: 1.000 đô la
20 cổ phiếu lần giao dịch
sumTarget = 0.6
Ngưỡng giảm mạnh là 1%.
windowMin = 15 phút
Kết quả: lợi tức đầu tư (ROI)-50% sau 2 ngày.
Điều này chứng tỏ rõ ràng rằng việc lựa chọn tham số là yếu tố quan trọng nhất. Nó có thể giúp bạn kiếm được rất nhiều tiền, hoặc cũng có thể dẫn đến những tổn thất đáng kể.
Những hạn chế của việc kiểm định ngược
Ngay cả khi đã tính đến chi phí và sự khác biệt về giá cả, việc kiểm thử ngược vẫn có những hạn chế nhất định.
Thứ nhất, nghiên cứu chỉ sử dụng dữ liệu từ một vài ngày, điều này có thể chưa đủ để có được cái nhìn toàn diện về thị trường.
Nó dựa trên giá bán tốt nhất được ghi nhận tại một thời điểm nhất định; trên thực tế, các lệnh có thể được thực hiện một phần hoặc được thực hiện ở các mức giá khác nhau. Hơn nữa, độ sâu sổ lệnh và khối lượng giao dịch khả dụng không được mô phỏng.
Các biến động dưới một giây không được ghi nhận ( dữ liệu được lấy mẫu một lần mỗi giây). Mặc dù quá trình kiểm tra ngược có dấu thời gian 1 giây, nhưng nhiều điều có thể xảy ra trong vòng một giây.
Trong quá trình kiểm thử ngược, độ trượt giá là không đổi và không có sự mô phỏng độ trễ thay đổi (ví dụ: 200–1500 mili giây) hoặc các xung đột mạng.
Mọi giao dịch đều được coi là thực hiện "ngay lập tức" (không có hàng đợi lệnh, không có lệnh chờ).
Phí được thu một cách thống nhất, nhưng trên thực tế, phí có thể phụ thuộc vào: thị trường/ token, bên đặt lệnh và bên nhận lệnh, mức phí hoặc các điều kiện.
Để giữ thái độ bi quan (thận trọng), tôi đã áp dụng một quy tắc: nếu Bước 2 không được thực hiện trước khi thị trường đóng cửa, Bước 1 sẽ được coi là thua lỗ hoàn toàn.
Đây là cách tiếp cận cố ý thận trọng, nhưng nó không phải lúc nào cũng phản ánh thực tế:
Đôi khi chặng 1 có thể kết thúc sớm.
Đôi khi nó lọt vào top những người thắng cuộc (ITM) và giành chiến thắng.
Đôi khi tổn thất chỉ là một phần chứ không phải hoàn toàn.
Mặc dù mức thiệt hại có thể bị ước tính quá cao, nhưng điều này cung cấp một kịch bản "tệ nhất" hữu ích.
Quan trọng hơn hết, việc kiểm tra lại dữ liệu quá khứ không thể mô phỏng tác động của các lệnh lớn của bạn lên sổ lệnh hoặc hành vi thu hút các nhà giao dịch khác nhắm mục tiêu vào bạn. Trên thực tế, các lệnh của bạn có thể:
Phá vỡ sổ lệnh .
Thu hút hoặc xua đuổi các thương nhân khác,
Điều này dẫn đến hiện tượng trượt phi tuyến tính.
Việc kiểm tra ngược giả định bạn chỉ là rút thanh khoản (người mua giá), vì vậy nó không có tác động gì.
Cuối cùng, nó không mô phỏng các giới hạn tốc độ, lỗi API, từ chối đơn hàng, tạm dừng, hết thời gian chờ, kết nối lại hoặc các tình huống robot đang bận và bỏ lỡ tín hiệu.
Kiểm thử ngược (backtesting) cực kỳ hữu ích để xác định phạm vi tham số phù hợp, nhưng nó không đảm bảo 100% vì một số hiệu ứng thực tế không thể mô phỏng được.
Cơ sở hạ tầng
Tôi dự định chạy robot trên Raspberry Pi để tránh tiêu tốn tài nguyên của máy chủ và để robot hoạt động liên tục 24/7.
Tuy nhiên, vẫn còn nhiều điểm cần cải thiện:
Việc sử dụng Rust thay vì JavaScript sẽ mang lại hiệu năng và thời gian xử lý vượt trội hơn nhiều.
Việc chạy một nút Polygon RPC chuyên dụng sẽ giúp giảm độ trễ hơn nữa.
Việc triển khai trên VPS gần máy chủ Polymarket cũng sẽ giúp giảm đáng kể độ trễ.
Chắc chắn vẫn còn phương pháp tối ưu hóa khác mà tôi chưa khám phá ra. Hiện tại, tôi đang học Rust vì nó đang trở thành một ngôn ngữ không thể thiếu trong phát triển Web3.
Twitter: https://twitter.com/BitpushNewsCN
Nhóm cộng đồng BitPush trên Telegram: https://t.me/BitPushCommunity
Đăng ký theo dõi Bitpush trên Telegram: https://t.me/bitpush
