Yield Farming با ۸۶٪ APY؟ نحوه استفاده از ربات‌ها برای «کسب درآمد در خواب» در Polymarket

عنوان اصلی: من یک ربات Polymarket ساختم و تنظیمات پارامترهای مختلف را آزمایش کردم، این نتایج است.

نویسنده اصلی: @the_smart_ape، محقق ارز دیجیتال

ترجمه اصلی: Bitpush News

چند هفته پیش، تصمیم گرفتم ربات Polymarket خودم را بسازم. نسخه کامل آن چندین هفته زمان برد تا تکمیل شود.

من مایل بودم این تلاش را انجام دهم زیرا واقعاً یک شکاف کارایی در Polymarket وجود دارد. اگرچه برخی از ربات‌ها در بازار در حال حاضر از این ناکارآمدی‌ها استفاده می‌کنند، اما هنوز کافی نیست و فرصت‌های موجود در این بازار هنوز بسیار بیشتر از تعداد ربات‌ها است.

Bot Building Logic

منطق ساخت ربات

منطق ربات بر اساس مجموعه‌ای از استراتژی‌هایی است که من در گذشته به صورت دستی اجرا کرده‌ام، که برای بهبود کارایی آن‌ها را خودکار کردم. ربات در بازار «BTC 15 دقیقه صعودی/نزولی» اجرا می‌شود.

ربات یک برنامه نظارت بلادرنگ را اجرا می‌کند که می‌تواند به طور خودکار به دور فعلی BTC 15 دقیقه سوئیچ کند، بهترین Ask Price را از طریق WebSocket ساده‌سازی کند، یک رابط کاربری ترمینال ثابت نمایش دهد و کنترل جامع از طریق دستورات متنی را امکان‌پذیر سازد.

در حالت دستی، می‌توانید مستقیماً سفارش ثبت کنید.

buy up <usd> / buy down <usd>: خرید مقدار مشخصی به دلار.

buyshares up <shares> / buyshares down <shares>: خرید مقدار دقیقی از سهام، با استفاده از سفارش LIMIT + GTC (Good 'Til Canceled) کاربرپسند، که با بهترین قیمت فروش فعلی اجرا می‌شود.

حالت خودکار یک حلقه دو مرحله‌ای تکرار شونده را اجرا می‌کند.

ابتدا، فقط حرکات قیمت را در عرض windowMin دقیقه در شروع هر دور مشاهده می‌کند. اگر هر یک از طرفین به اندازه کافی سریع کاهش یابد (رسیدن به درصد کاهش حداقل movePct در حدود 3 ثانیه)، «مرحله 1» را فعال می‌کند و طرفی که کاهش شدید را تجربه کرده است، خریداری می‌کند.

پس از تکمیل مرحله 1، ربات دیگر هرگز همان طرف را خریداری نخواهد کرد. منتظر «مرحله دوم (مرحله 2، یعنی هج)» می‌ماند و تنها در صورتی فعال می‌شود که شرط زیر برآورده شود: leg1EntryPrice + oppositeAsk <= sumTarget.

هنگامی که این شرط برآورده شود، طرف مقابل را خریداری می‌کند. پس از تکمیل مرحله 2، چرخه به پایان می‌رسد، ربات به حالت مشاهده باز می‌گردد و با استفاده از همان پارامترها منتظر سیگنال سقوط ناگهانی بعدی می‌ماند.

اگر در طول چرخه تغییری در دور ایجاد شود، ربات چرخه باز را رها کرده و با همان تنظیمات در دور بعدی دوباره شروع می‌کند.

تنظیمات پارامتر برای حالت خودکار به شرح زیر است: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: اندازه موقعیت برای معامله دو مرحله‌ای.

· sum: آستانه برای هجینگ مجاز.

· move (movePct): آستانه سقوط ناگهانی (به عنوان مثال، 0.15 = 15%).

· windowMin: زمان از شروع هر دور برای اجازه اجرای مرحله 1.

Backtesting

بک‌تست

منطق ربات ساده است: منتظر یک سقوط ناگهانی شدید باشید، طرفی که به تازگی کاهش یافته را بخرید، سپس منتظر بمانید تا قیمت تثبیت شود و با خرید طرف مقابل هج کنید، اطمینان حاصل کنید که priceUP + priceDOWN < 1.

اما این منطق باید آزمایش شود. آیا واقعاً در دراز مدت موثر است؟ مهم‌تر از آن، ربات پارامترهای زیادی دارد (shares، sum، درصد حرکت، دقیقه پنجره و غیره). کدام مجموعه پارامتر بهینه است و سود را به حداکثر می‌رساند؟

اولین فکر من این بود که ربات را به مدت یک هفته به صورت زنده اجرا کنم و نتایج را مشاهده کنم. مشکل این است که این کار خیلی طول می‌کشد و فقط می‌تواند یک مجموعه پارامتر را آزمایش کند، در حالی که من نیاز به آزمایش بسیاری دارم.

دومین فکر من این بود که با استفاده از داده‌های تاریخی آنلاین از API Polymarket CLOB بک‌تست بگیرم. متأسفانه، برای بازار صعودی/نزولی 15 دقیقه‌ای BTC، نقطه پایانی داده‌های تاریخی به طور مداوم مجموعه‌های داده خالی را برمی‌گرداند. بدون تیک‌های قیمت تاریخی، بک‌تست نمی‌تواند «سقوط ناگهانی حدود 3 ثانیه‌ای» را تشخیص دهد، نمی‌تواند مرحله 1 را فعال کند و صرف نظر از پارامترهای استفاده شده، منجر به 0 چرخه و 0% بازگشت سرمایه (ROI) می‌شود.

پس از بررسی بیشتر، متوجه شدم که کاربران دیگر نیز هنگام بازیابی داده‌های تاریخی برای بازارهای خاص با همین مشکل مواجه شدند. من بازارهای دیگری را آزمایش کردم که واقعاً داده‌های تاریخی را برمی‌گرداندند و به این نتیجه رسیدم که برای این بازار خاص، داده‌های تاریخی به سادگی حفظ نشده‌اند.

به دلیل این محدودیت، تنها راه مطمئن برای بک‌تست این استراتژی، ایجاد مجموعه داده تاریخی خودم با ثبت بهترین قیمت‌های فروش بلادرنگ در حین اجرای ربات است.

ضبط‌کننده اسنپ‌شات‌ها را روی دیسک می‌نویسد، از جمله موارد زیر:

· زمان

· Round Slug

· ثانیه‌های باقی‌مانده

· شناسه توکن صعودی/نزولی

· بهترین قیمت فروش صعودی/نزولی

پس از آن، «بک‌تست ضبط شده» این اسنپ‌شات‌ها را بازپخش می‌کند و همان منطق خودکار را به صورت قطعی اعمال می‌کند. این امر توانایی به دست آوردن داده‌های با فرکانس بالا مورد نیاز برای تشخیص سقوط ناگهانی و شرایط هجینگ را تضمین می‌کند.

طی 4 روز، در مجموع 6 گیگابایت داده جمع‌آوری کردم. می‌توانستم بیشتر ضبط کنم، اما فکر کردم این برای آزمایش مجموعه‌های پارامتر مختلف کافی است.

شروع به آزمایش این مجموعه پارامتر کردم:

· موجودی اولیه: 1000 دلار

· 20 سهم در هر معامله

· sumTarget = 0.95

· آستانه سقوط ناگهانی = 15%

· windowMin = 2 دقیقه

من همچنین 0.5% کارمزد ثابت و 2% اسپرد را اعمال کردم تا در سناریوی محافظه‌کارانه باقی بمانم.

بک‌تست ROI 86% را نشان داد که 1000 دلار را تنها در چند روز به 1869 دلار تبدیل کرد.

سپس، مجموعه پارامتر تهاجمی‌تری را آزمایش کردم:

· موجودی اولیه: 1000 دلار

· 20 سهم در هر معامله

· sumTarget = 0.6

· آستانه سقوط ناگهانی = 1%

· windowMin = 15 دقیقه

نتیجه: پس از 2 روز، سرمایه‌گذاری نرخ بازگشت 50%- داشت.

این به وضوح نشان می‌دهد که انتخاب پارامتر مهم‌ترین عامل است. می‌تواند شما را به پول زیادی برساند یا منجر به ضررهای قابل توجهی شود.

Limitations of Backtesting

محدودیت‌های بک‌تست

حتی با احتساب هزینه‌ها و اسپردها، بک‌تست محدودیت‌های خود را دارد.

· اولاً، فقط از داده‌های چند روز استفاده می‌کند که ممکن است برای به دست آوردن دیدگاه جامع بازار کافی نباشد.

· به اسنپ‌شات‌های بهترین قیمت فروش ثبت‌شده متکی است؛ در واقعیت، سفارش‌ها ممکن است به صورت جزئی پر شوند یا با قیمت‌های متفاوتی پر شوند. علاوه بر این، عمق دفتر سفارش و حجم موجود مدل‌سازی نمی‌شوند.

· نوسانات خرد زیر ثانیه ثبت نمی‌شوند (داده‌ها هر ثانیه نمونه‌برداری می‌شوند). اگرچه بک‌تست دارای زمان‌بندی در سطح 1 ثانیه است، اما در بین هر ثانیه اتفاقات زیادی می‌تواند رخ دهد.

· Slippage اسلیپیج در بک‌تست ثابت است، بدون شبیه‌سازی تأخیرهای متغیر (به عنوان مثال، 200-1500 میلی‌ثانیه) یا اوج‌های ازدحام شبکه.

· فرض بر این است که هر بخش معامله «به صورت آنی» اجرا می‌شود (بدون صف سفارش، بدون سفارش‌های معلق).

· هزینه‌ها به طور یکنواخت دریافت می‌شوند، در حالی که در واقعیت، هزینه‌ها ممکن است به موارد زیر بستگی داشته باشند: بازار/توکن، میکر-تیکر، سطوح کارمزد، یا شرایط.

برای حفظ رویکرد بدبینانه (محتاطانه)، من یک قانون اعمال کردم: اگر مرحله 2 قبل از بسته شدن بازار اجرا نشود، مرحله 1 یک ضرر کامل در نظر گرفته می‌شود.

اگرچه عمداً محافظه‌کارانه است، اما این همیشه با واقعیت مطابقت ندارد:

· گاهی اوقات مرحله 1 می‌تواند زودتر بسته شود،

· گاهی اوقات در نهایت در سود (ITM) قرار می‌گیرد و برنده می‌شود،

· گاهی اوقات ضرر می‌تواند جزئی باشد نه کامل.

اگرچه ممکن است ضرر بیش از حد ارزیابی شود، اما این یک سناریوی «بدترین حالت» عملی را ارائه می‌دهد.

مهم‌تر از همه، بک‌تست نمی‌تواند تأثیر سفارش‌های بزرگ شما بر دفتر سفارش یا جذب رفتار غارتگرانه از سوی سایر معامله‌گران را شبیه‌سازی کند. در واقعیت، سفارش شما می‌تواند:

· دفتر سفارش را مختل کند،

· سایر معامله‌گران را جذب یا دفع کند،

· باعث اسلیپیج غیرخطی شود.

بک‌تست فرض می‌کند شما یک استخراج‌کننده نقدینگی خالص (گیرنده قیمت) بدون هیچ تأثیری هستید.

در نهایت، محدودیت‌های نرخ، خطاهای API، رد سفارش، توقف‌ها، تایم‌اوت‌ها، اتصال مجدد یا موقعیت‌هایی که ربات مشغول است و سیگنال‌ها را از دست می‌دهد، شبیه‌سازی نمی‌کند.

بک‌تست برای شناسایی محدوده خوبی از پارامترها بسیار ارزشمند است، اما تضمین 100% نیست زیرا برخی از اثرات دنیای واقعی قابل مدل‌سازی نیستند.

Infrastructure

زیرساخت

من قصد دارم این ربات را روی یک Raspberry Pi اجرا کنم تا از مصرف منابع روی دستگاه اصلی خود جلوگیری کنم و آن را 24/7 روشن نگه دارم.

با این حال، هنوز فضای زیادی برای بهبود وجود دارد:

· استفاده از Rust به جای JavaScript عملکرد و زمان پردازش بسیار بهتری را ارائه می‌دهد.

· اجرای یک node نود اختصاصی Polygon RPC تأخیر را بیشتر کاهش می‌دهد.

· استقرار روی یک VPS نزدیک به سرور Polymarket نیز تأخیر را به طور قابل توجهی کاهش می‌دهد.

مطمئنم روش‌های بهینه‌سازی دیگری وجود دارد که هنوز کشف نکرده‌ام. در حال حاضر، من در حال یادگیری Rust هستم زیرا در حال تبدیل شدن به یک زبان ضروری در توسعه Web3 است.

Original Article Link لینک مقاله اصلی