بررسی اینکه آیا pool شما منصفانه پرداخت می‌کند: روشی 30 روزه که خودتان می‌توانید اجرا کنید

دیر یا زود هر ماینری همین سوال را می‌پرسد. درآمد کاهش یافته در حالی که difficulty ثابت مانده، یا داشبورد pool hashrate کمتری نسبت به آنچه دستگاه گزارش می‌دهد نشان می‌دهد، یا هفته با luck معادل 82% به پایان رسیده و چت از قبل درباره سرقت صحبت می‌کند.

بخشی از این سوال قابل پاسخ‌گویی است. بخشی دیگر نیست، و هیچ مقدار کار با spreadsheet این را تغییر نمی‌دهد. داده‌های بلاک، انتساب coinbase و تراکنش‌های payout خود شما عمومی هستند. آنچه در داخل pool بین share ارسالی شما و موجودی شما اتفاق می‌افتد، تنها از طریق گزارش‌دهی خود pool قابل مشاهده است.

POOL BTC یک pool نیست. ما شرایط دیگران را مقایسه می‌کنیم و محاسبه می‌کنیم که برای یک ماینر چقدر هزینه دارد، پس آنچه در ادامه می‌آید یک رویه است، نه یک اتهام. آن را با اعداد خودتان اجرا کنید.

واقعاً چه چیزی را می‌توانید تأیید کنید، و چه چیزی هرگز قابل تأیید نیست؟

شما می‌توانید هر آنچه روی blockchain ثبت شده یا با hardware خودتان اندازه‌گیری شده را کاملاً تأیید کنید: بلاک‌هایی که pool پیدا کرده، fee های داخل آن بلاک‌ها، مبالغی که به آدرس شما رسیده، hashrate شما و reject rate شما. هر چیز داخلی pool، از حسابداری share تا پنجره PPLNS، برای شما فقط به شکل یک گزارش وجود دارد.

نتیجه‌گیری صادقانه از آن جدول این است: یک ماینر نمی‌تواند fraud را اثبات کند. یک ماینر می‌تواند به خودش ثابت کند که هیچ مغایرتی وجود ندارد، و اگر مغایرتی وجود داشته باشد، آن را مکان‌یابی کرده و به صورت یک محاسبه ریاضی جلوی operator بگذارد.

چرا داشبورد pool hashrate کمتری نسبت به ASIC شما نشان می‌دهد؟

چون آن‌ها چیزهای متفاوتی را اندازه می‌گیرند. دستگاه شما سرعت hashing لحظه‌ای را گزارش می‌دهد. pool پس از وقوع، hashrate شما را از روی share های پذیرفته‌شده در طول یک پنجره میانگین‌گیری تخمین می‌زند. این دو ذاتاً نمی‌توانند مطابقت داشته باشند، چون pool فقط چیزی را می‌شمارد که به آن رسیده و اعتبارسنجی را پشت سر گذاشته است.

چهار دلیل معمول برای این شکاف:

1. پنجره میانگین‌گیری. عدد پنج‌دقیقه‌ای ده‌ها درصد نوسان می‌کند، عدد 24 ساعته صاف و یکنواخت است. روزانه را با روزانه مقایسه کنید، هرگز لحظه‌ای را با روزانه مقایسه نکنید.
2. واریانس share. پیدا کردن یک share یک فرآیند تصادفی است، و پنجره‌های کوتاه نویز واقعی با خود دارند.
3. share های reject شده و stale. این‌ها از حسابداری خارج می‌شوند، بنابراین hashrate مؤثر شما پایین‌تر از nameplate قرار می‌گیرد.
4. تأخیر شبکه. هرچه سرور Stratum دورتر باشد و کیفیت اتصال بدتر باشد، کار بیشتری از قبل منسوخ‌شده می‌رسد.

برخی pool ها چیزی را که آن را reject rate عادی می‌دانند منتشر می‌کنند. اعداد منتشرشده با یکدیگر مغایرت دارند، و هیچ استاندارد صنعتی وجود ندارد.

منبع: صفحات پشتیبانی AntPool، ViaBTC و F2Pool، بررسی‌شده در 09.09.2026. این صفحات برای دریافت خودکار کد 403 برمی‌گردانند، بنابراین نقل‌قول‌ها از قطعات نتایج جست‌وجو برای همان URL ها گرفته شده‌اند، نه از متن اصلی صفحات. اگر عبارت دقیق برای شما اهمیت دارد، ارزش دارد که آن را به‌صورت دستی باز کنید.

دامنه بین 0.5% و 3% یک معنای عملی دارد: "عادی" برای pool شما توسط خود pool شما تعریف می‌شود، نه توسط صنعت. یک آستانه هشدار کاربردی، یک شکاف پایدار بالای 5% در عدد روزانه است که reject rate شما آن را توضیح نمی‌دهد.

چگونه درآمد مورد انتظار را محاسبه کرده و آن را با درآمد واقعی مقایسه می‌کنید؟

سهم خود را از hashrate شبکه بگیرید، آن را در block reward مؤثر و در تعداد بلاک‌ها در روز ضرب کنید. یک فرمول برای همه schemeها کاربرد دارد. چیزی که بین scheme ها تغییر می‌کند این است که credit واقعی تا چه حد اجازه دارد از آن خط منحرف شود: در FPPS تقریباً هیچ، در PPLNS به‌طور محسوس.

\`\`\`

miner share = miner hashrate / network hashrate

reward_eff = 3.125 BTC × (1 + transaction fee share)

BTC per day = miner share × 144 × reward_eff × (1 - pool fee)

\`\`\`

با استفاده از snapshot شبکه برای 09.09.2026: hashrate شبکه 943.73 EH/s، transaction fee share طی 4320 بلاک اخیر 0.669%، بنابراین reward_eff = 3.125 × 1.00669 = 3.1459 BTC. Difficulty در همان تاریخ برابر با 127,450,789,715,843.1 بود (mempool.space، دسترسی در 09.09.2026).

FPPS و PPS+: credit روزانه باید ثابت باشد

در FPPS، pool به ازای هر share ارسالی، شامل کارمزد تراکنش، نرخ ثابتی پرداخت می‌کند، صرف‌نظر از اینکه آن روز بلاکی پیدا کرده باشد یا نه. بنابراین credit روزانه شما باید از نزدیک از خط محاسبه‌شده پیروی کند. دوشنبه‌ای که نصف سه‌شنبه را با hashrate یکسان پرداخت می‌کند واریانس scheme در FPPS نیست، بلکه چیزی است که باید درباره‌اش سوال کرد.

PPS+ روی subsidy به همان شکل عمل می‌کند، اما کارمزد تراکنش را بر اساس بلاک‌هایی که واقعاً پیدا شده‌اند توزیع می‌کند، بنابراین یک اختلاف روزانه ملایم قابل انتظار است. اینکه این scheme ها روی همان hashrate چقدر به دلار تبدیل می‌شوند در مقاله FPPS, PPS+, PPLNS and SOLO بررسی شده است.

PPLNS: فقط در یک پنجره زمانی طولانی مقایسه کنید

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

خود مقایسه:

1. hashrate روزانه خود را از داشبورد pool برای هر روز از این دوره ثبت کنید.
2. hashrate شبکه و transaction fee share را برای هر یک از آن تاریخ‌ها ثبت کنید، نه یک عدد برای کل ماه. بین 29.08 و 09.09.2026 شبکه از 896.89 به 943.73 EH/s رسید، یعنی 5.2% افزایش، و هر کسی که hardware خود را تغییر نداده دقیقاً همین مقدار را از دست داده است.
3. انتظار را برای هر روز محاسبه کرده و آن را جمع بزنید.
4. credit های واقعی همان روزها را از گزارش pool جمع بزنید.
5. این دو مجموع را با هم مقایسه کرده و شکاف را به‌صورت درصد بیان کنید.
6. به‌طور جداگانه، آنچه واقعاً به wallet شما رسیده را جمع بزنید و آن را با آنچه از موجودی pool شما خارج شده مقایسه کنید. این‌ها دو بررسی متفاوت هستند: credit دادن و تحویل.

اعداد خودتان را از طریق mining calculator اجرا کنید، زمان‌بندی payout هر pool را در صفحه payout time بررسی کنید، و ببینید ما چگونه تخمین‌های خودمان را در روش‌شناسی می‌سازیم.

luck pool چیست، و آیا luck پایین تقلب را ثابت می‌کند؟

luck نسبت بلاک‌هایی است که واقعاً پیدا شده‌اند به تعدادی که از hashrate pool در طول یک دوره انتظار می‌رفت. در 100%، pool دقیقاً همان چیزی را پیدا کرده که آمار پیش‌بینی کرده بود. این یک متغیر تصادفی است، بنابراین یک هفته با 80% یا 130% پراکندگی معمولی است و دلیلی بر هیچ چیز نیست.

بخشی که اکثر بحث‌ها از قلم می‌اندازند: در FPPS و PPS، luck اصلاً به payout شما دست نمی‌زند. pool یک نرخ پرداخت می‌کند و خودش دوره‌های بدشانسی را جذب می‌کند، که دقیقاً همان چیزی است که fee بالاتر نسبت به PPLNS می‌خرد. درخواست محاسبه مجدد پس از یک هفته بدشانس در FPPS منطقی نیست، چون آن هفته از قبل با نرخ فرمول پرداخت شده است.

در PPLNS و TIDES، luck مستقیماً تأثیر می‌گذارد: نبود بلاک به معنای نبود توزیع است. luck پایین در آنجا واقعاً درآمد شما را کاهش می‌دهد، اما این ویژگی scheme است، نه اقدام operator. آن را در طول یک فصل قضاوت کنید، و فقط زمانی که block share pool در جداول عمومی ثابت مانده باشد.

سه چیز که پیش از نتیجه‌گیری از یک عدد luck ارزش بررسی دارند:

1. پنجره: به ازای هر round، هر روز، یا rolling 30 روزه. پنجره‌های مختلف داستان‌های متفاوتی از داده‌های یکسان روایت می‌کنند.
2. اینکه آیا luck بر اساس تعداد بلاک محاسبه می‌شود یا بر اساس round share ها. دومی پایدارتر است.
3. اینکه آیا تعداد بلاک در گزارش pool با تعدادی که explorer های عمومی به آن نسبت می‌دهند مطابقت دارد.

یک مرجع آماده به شکل "luck هفتگی در یک pool بزرگ این‌طوری است" چیزی نیست که بتوانیم به شما بدهیم، و ارزش دارد از همان ابتدا دلیلش را بدانید. هیچ‌یک از منابعی که بررسی کردیم یک سری از luck هفتگی یا ماهانه واقعی طی دوازده ماه گذشته را همراه با یک روش‌شناسی مشخص منتشر نمی‌کند. آنچه واقعاً تا تاریخ 2026-09-11 وجود دارد این است:

1. F2Pool ویجت‌های luck را برای 3، 7، 30 و 90 روز در صفحه آمار خود نشان می‌دهد و یک لاگ جداگانه از بلاک‌های پیدا شده به همراه luck هر کدام نگه می‌دارد. این‌ها پنجره‌های rolling در همین لحظه هستند، نه آرشیوی از هفته‌های سال گذشته. pool روش خود را در help center بیان می‌کند: بلاک‌های واقعاً پیدا شده تقسیم بر تعدادی که از نظر تئوری از hashrate pool انتظار می‌رفت.
2. ViaBTC همان فرمول را در بلاگ خود با یک مثال محاسبه‌شده توضیح می‌دهد: luck هفت‌روزه 92.17% در تاریخ 2024-05-07. هیچ سری منتشرشده مستمری در آنجا وجود ندارد، این فقط یک نمونه توضیحی از روش است.
3. Antpool هیچ صفحه luck عمومی اختصاصی در منابع رسمی خود ندارد.
4. Braiins یک توزیع تاریخی hashrate ماه‌به‌ماه بین pool ها را از سال 2012 تاکنون منتشر می‌کند، اما آن سهم قدرت است، نه luck.
5. ردیاب‌های مستقل مانند soloblocks.io و blocksrace.com luck را با همان فرمول در پنجره‌های کوتاه، از چند ساعت تا 30 روز محاسبه می‌کنند. اولی صریحاً اعلام می‌کند که هنوز داده سالانه‌ای جمع‌آوری نکرده است: این سرویس از مارس 2026 در حال اجرا بوده است.

نتیجه‌گیری عملی ساده است. pool خود را نه با یک "هنجار" صنعتی که به‌صورت عمومی در دسترس نیست، بلکه با عدد خودش در طول یک پنجره طولانی مقایسه کنید: در جایی که pool آن را منتشر می‌کند به luck 90 روزه نگاه کنید، و تعداد بلاک را با جداول explorer عمومی متقابلاً بررسی کنید. دقیقاً به همین دلیل است که بخش بعدی درباره بلاک‌ها است، نه luck.

چگونه تأیید می‌کنید که یک pool واقعاً بلاک پیدا می‌کند؟

از طریق تراکنش coinbase. هر بلاک یکی از این‌ها را با خود دارد، و pool ها یک تگ متنی و آدرس reward را در آن قرار می‌دهند. explorer ها این تگ‌ها را در جداول انتساب جمع‌آوری می‌کنند، به همین دلیل هر کسی می‌تواند تعداد بلاک‌های یک pool مشخص را بدون هیچ دسترسی به داشبورد آن بشمارد.

روش کار:

1. جدول pool ها را در mempool.space برای پنجره‌های یک‌هفته‌ای و یک‌ماهه باز کنید.
2. pool خود را پیدا کرده و تعداد بلاک و share آن را یادداشت کنید.
3. آن share را با هر چیزی که pool درباره hashrate خودش در سایتش ادعا می‌کند مقایسه کنید.
4. دو بلاک مشخص از گزارش خود pool بردارید و آن‌ها را بر اساس height جست‌وجو کنید. coinbase باید تگ آن pool را با خود داشته باشد.
5. اگر pool اصلاً هرگز در جداول عمومی ظاهر نمی‌شود، از support بپرسید چرا. "ما coinbase خود را تگ نمی‌کنیم" یک پاسخ قابل بررسی است. "حساس تجاری" این‌طور نیست.

در ادامه توزیع بر اساس mempool.space در تاریخ 11.09.2026 آمده است:

پنجره هفتگی 1026 بلاک را پوشش می‌دهد، پنجره ماهانه 4497 بلاک را. منبع هر دو: mempool.space Mining Pools API، دسترسی در 11.09.2026.

یک نکته روش‌شناختی. block share یک نماینده برای hashrate است، نه اندازه‌گیری آن، پس ستون‌های هفتگی و ماهانه را با هم بخوانید. یک یا دو واحد اختلاف بین آن‌ها، مانند SECPOOL و NiceHash در بالا، یک واریانس معمولی روی تعدادهای کوچک است، نه اینکه یک pool ماشین به‌دست آورده یا از دست داده باشد. اینکه واقعاً چه کسی محتوای یک بلاک را می‌سازد، و چرا این یک سوال جداگانه است، در مقاله Stratum V2 بررسی شده است.

در FPPS، کارمزد تراکنش‌های داخل یک بلاک به کجا می‌رود؟

در یک پیاده‌سازی درست FPPS، آن‌ها وارد نرخ شما می‌شوند. pool fee share را در بلاک‌های اخیر میانگین می‌گیرد، آن را به subsidy اضافه می‌کند، و fee خودش را از مجموع کسر می‌کند. این کل تفاوت با PPS ساده است، جایی که شما فقط بر اساس subsidy پرداخت می‌شوید و fee ها نزد pool می‌ماند.

در حال حاضر این مقدار کم است. طبق mempool.space، کارمزد تراکنش 0.66% از block reward ها را طی 4320 بلاک اخیر در 08.09.2026 و 0.669% در 09.09.2026 تشکیل داده، در حالی که یک پنجره 144 بلاکی عدد 0.57% را نشان داده. طی ماه گذشته، این محدوده بین 0.66-0.73% قرار دارد، که یک بازار fee آرام بدون هیچ رویدادی از نوع Ordinals یا Runes است.

aggregator های مختلف از یک chain واحد اعداد متفاوتی تولید می‌کنند، و این روش‌شناسی است، نه خطا. در اوایل سپتامبر 2026، معیارهای روزانه از Glassnode و Newhedge عدد 0.40-0.56% را در برابر 0.66-0.70% از mempool.space طی 4320 بلاک نشان دادند. پس وقتی مغایرتی را با یک pool مطرح می‌کنید، منبع، پنجره و تاریخ را ذکر کنید، وگرنه درباره اعدادی بحث می‌کنید که تحت قوانین متفاوتی محاسبه شده‌اند.

بازارهای fee آرام تا ابد دوام نمی‌آورند. در 20.04.2024، یک روز پس از halving و راه‌اندازی Runes، fee ها بسته به روش‌شناسی به 73.8-75% از درآمد ماینر رسیدند، و در 08.05.2023 در اوج Ordinals به 40.8-42.59% برای آن روز رسیدند. در روزهایی مثل آن‌ها، شکاف بین FPPS و PPS دیگر یک موضوع صرفاً آکادمیک نیست، که لحظه خوبی است برای بازخوانی آنچه مستندات pool شما درباره کارمزد تراکنش می‌گوید.

چه چیزی را در اینجا باید بررسی کرد:

1. مستندات واقعاً کدام scheme را نام می‌برد: FPPS، PPS+ یا PPS. در متن یک کلمه فاصله، در پول چند واحد درصد فاصله.
2. اینکه آیا pool پنجره‌ای را که fee share را روی آن میانگین می‌گیرد منتشر می‌کند یا نه.
3. اینکه آیا بخش fee از credit شما با fee share عمومی برای آن تاریخ‌ها، حداقل از نظر مرتبه بزرگی، مطابقت دارد.

علاوه بر fee pool، چه چیز دیگری کسر می‌شود؟

چهار مکانیزم: کارمزد شبکه روی تراکنش payout، آستانه حداقل payout، رند کردن روی credit ها، و spread روی هر نوع تبدیل. هیچ‌کدام از این‌ها تقلب نیست، همگی حداقل توسط برخی pool ها مستند شده‌اند، و مجموعاً بیشتر موارد کاهش‌یافته نسبت به آنچه انتظار می‌رفت را توضیح می‌دهند.

کارمزدهای ثابت withdrawal یادداشت جداگانه خودشان را می‌طلبند، چون به درصدی تبدیل می‌شوند که به مبلغ بستگی دارد. Kryptex App مبلغ 0.00003 BTC روی chain در مقابل حداقل 0.00025 BTC دریافت می‌کند، که 12% از کوچک‌ترین withdrawal ممکن و 0.3% روی یک withdrawal 0.01 BTC است. Lightning در همین سرویس 2% هزینه دارد با حداقل 0.00001 BTC: از نظر مطلق ارزان‌تر، اما به‌عنوان نرخ گران‌تر است.

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

این یک محاسبه انتظاری بر اساس hashrate شبکه 943.73 EH/s و reward مؤثر 3.1459 BTC است، نه داده pool. واریانس PPLNS و TIDES در آن لحاظ نشده است.

برای F2Pool و ViaBTC این قانون واقعاً در help center رسمی وجود دارد، و به نفع ماینر است.

F2Pool در صفحه راهنمای خود بیان می‌کند که برای پرداخت درآمد mining هیچ کارمزد تراکنشی دریافت نمی‌کند، به شرطی که موجودی از آستانه حداقل عبور کرده باشد. آن آستانه برای BTC طبق جدول خود pool برابر 0.005 BTC است و توسط کاربر قابل تنظیم است. مورد جداگانه، withdrawal دستی زیر آستانه است: این از 10% مقدار پیش‌فرض، یعنی از 0.0005 BTC، در دسترس است، فقط از طریق Lightning انجام می‌شود، و در آنجا کارمزد 0.000001 BTC توسط ماینر پرداخت می‌شود. pool قانون معکوس را برای ETHW و ALEO بیان می‌کند، که در مورد bitcoin کاربرد ندارد.

ViaBTC حتی صریح‌تر بیان می‌کند: auto-withdrawal بالای حداقل در help center به‌عنوان کاملاً رایگان توصیف شده، و یک اعلامیه در همان بخش می‌گوید pool همچنان تمام هزینه تراکنش را می‌پردازد. حداقل auto-withdrawal برای BTC برابر 0.001 BTC است. تنها جایی که ابهام دارد، Normal Transfer دستی است: FAQ رسمی اذعان می‌کند که fee آن با ازدحام شبکه شناور است، اما صفحه نمی‌گوید چه کسی آن را پرداخت می‌کند. ما به‌جای pool حدس نمی‌زنیم، پس مبلغ را روی صفحه withdrawal پیش از تأیید بررسی کنید.

سه لینک همه این‌ها را تأیید می‌کنند: مقاله راهنمای F2Pool درباره کارمزدهای payout، صفحه ViaBTC درباره تنظیم auto-withdrawal و FAQ واریز و برداشت ViaBTC. دسترسی در 2026-09-11.

کدام مغایرت‌ها واقعاً نگران‌کننده هستند؟

آن‌هایی که واریانس توضیحشان نمی‌دهد و زمان پاکشان نمی‌کند. یک هفته بد در PPLNS، یک کسری روزانه 3% در FPPS، یک افت hashrate پنج‌دقیقه‌ای در داشبورد: نویز. کسری‌ای که پس از اینکه انتظار را با پارامترهای درست شبکه برای هر تاریخ دوباره محاسبه کردید، طی یک ماه ادامه دارد: یک سیگنال.

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

چک‌لیست 30 روزه

این توالی همه موارد بالا را پوشش می‌دهد و چیزی فراتر از دسترسی به دستگاه‌های شما، حساب pool شما و یک browser نیاز ندارد.

1. روز 0. ورودی‌ها را ثبت کنید: مدل و تعداد hardware، hashrate nameplate، scheme payout، fee اعلام‌شده، آستانه payout، آدرس payout. به‌جای کپی کردن عدد، از صفحه قیمت‌گذاری screenshot بگیرید. صفحات بی‌سروصدا تغییر می‌کنند.
2. روز 0. ثبت لاگ hashrate محلی را از خود دستگاه‌ها راه‌اندازی کنید. بدون آن، شما فقط داده pool را در برابر داده pool بررسی می‌کنید. حداقل مانیتورینگ و alerting قابل‌قبول در یک مقاله جداگانه بررسی شده است.
3. روزانه. چهار عدد را یادداشت کنید: hashrate روزانه طبق دستگاه‌های شما، hashrate روزانه طبق داشبورد، credit آن روز، reject rate.
4. روزانه. hashrate شبکه و transaction fee share را برای همان تاریخ ثبت کنید. یک snapshot برای کل ماه نتیجه را منحرف می‌کند: شبکه در یازده روز پایان آگوست 2026، 5.2% رشد کرد.
5. هفتگی. تعداد بلاک pool در جداول عمومی را با تعداد در گزارش خودش مقایسه کنید.
6. هفتگی. هر payout واردشده را در یک explorer بررسی کنید: مبلغ تراکنش، مبلغ کسرشده از موجودی، کارمزد شبکه، و چه کسی آن را پرداخت کرده است.
7. روز 30. انتظارات روزانه و credit های واقعی را جمع بزنید، سپس شکاف را به‌صورت درصد بیان کنید.
8. روز 30. به‌طور جداگانه تفاوت بین آنچه credit شده و آنچه به wallet شما رسیده را محاسبه کنید. هر چیزی که بین این دو عدد گم شده باید توسط آستانه، کارمزد شبکه یا یک تبدیل توضیح داده شود.
9. روز 30. درصد را با scheme خودتان بسنجید. در FPPS، شکاف ماهانه بالای 10% نیاز به توضیح دارد. در PPLNS، پیش از هرگونه نتیجه‌گیری، پنجره را به یک فصل تمدید کنید.
10. روز 30. اگر شکاف پس از آن باقی ماند، به بخش بعدی بروید نه به یک اتاق چت.

وقتی مغایرت باقی می‌ماند چه باید کرد

یک تیکت support باز کنید که از اعداد، تاریخ‌ها و یک سوال تشکیل شده است. نه از جمله "شما از من دزدی می‌کنید". یک operator که به این نوع درخواست پاسخ می‌دهد، به درخواست شما هم پاسخ خواهد داد، و یکی که یک محاسبه کتبی 30 روزه را نادیده می‌گیرد، از قبل چیزی به شما گفته است.

چه چیزی را باید پیوست کرد:

1. دوره مقایسه با تاریخ‌های دقیق، به‌همراه login یا worker ID های شما.
2. یک جدول روزانه: hashrate شما، hashrate داشبورد، credit، reject rate.
3. محاسبه انتظاری همراه با فرمول و منبع پارامترهای شبکه برای هر تاریخ.
4. شکاف کل به BTC و به درصد.
5. فهرست تراکنش‌های payout همراه با hash ها و مبالغ.
6. یک سوال مشخص. برای مثال: چه چیزی شکاف بین درآمد credit‌شده و درآمد مورد انتظار طی این دوره در این hashrate تحت این scheme را توضیح می‌دهد.

سپس پاسخ را بخوانید. تفکیک اعداد شما، ارجاع به یک قانون مستند، یا اذعان به یک رخداد همراه با محاسبه مجدد، همگی نتایج قابل‌قبولی هستند. صحبت کلی درباره نوسان و واریانس شبکه، که بدون هیچ عددی در پاسخ به یک جدول پر از عدد ارائه شود، یک نشانه بد است، به‌ویژه برای بار دوم.

چه زمانی تعویض pool تصمیم درستی است:

1. شکاف بیش از 30 روز ادامه داشته و پس از دو درخواست بدون توضیح مانده است.
2. تأخیرهای payout سیستماتیک شده‌اند.
3. pool دیگر در جداول بلاک عمومی ظاهر نمی‌شود، یا share آن به‌شدت از ادعاهایش فاصله دارد.
4. شرایط به‌صورت گذشته‌نگر و بدون اطلاع تغییر کرده‌اند.

جابه‌جایی هزینه دارد: چند ساعت downtime، یک پنجره PPLNS ازدست‌رفته در pool قبلی، و موجودی زیر آستانه که ممکن است فقط همان‌جا باقی بماند. قانون اینکه موجودی زیر آستانه انباشته می‌شود نه اینکه منقضی شود، به‌طور رسمی برای F2Pool، ViaBTC و Luxor تأیید شده است. برای pool های دیگر ما هیچ بیانیه صریحی در هیچ‌کدام از دو جهت پیدا نکردیم، پس پیش از رفتن آن را یک سوال باز در نظر بگیرید. نگه‌داشتن یک pool پشتیبان که در اسلات‌های ASIC پیکربندی شده باشد، تعویض را به کار چند دقیقه‌ای تبدیل می‌کند، که در مقاله failover بررسی شده است. پیش از جابه‌جایی، شرایط را در جدول مقایسه pool مقایسه کنید.

این روش چه کاری انجام نمی‌دهد

این روش fraud را ثابت نمی‌کند و جایگزین یک audit نمی‌شود. این به شما می‌گوید که آیا شکافی بین آنچه خودتان می‌توانید محاسبه کنید و آنچه به شما credit داده شده وجود دارد یا نه. هر چیزی پس از آن یک گفت‌وگو با operator است، نه یک پرونده حقوقی.

موارد زیر همچنان در داده‌های خود ما تا تاریخ 2026-09-11 تأییدنشده باقی مانده‌اند:

1. نرخ‌های دقیق fee در AntPool، Binance Pool، Foundry USA و Braiins. صفحات رسمی یا بارگذاری نمی‌شوند، یا عددی منتشر نمی‌کنند، یا با منابع دیگر تناقض دارند.
2. کارمزدهای withdrawal و قانون "چه کسی کارمزد شبکه را پرداخت می‌کند" در F2Pool و ViaBTC.
3. نرخ‌های spread autoconversion در EMCD و Kryptex.
4. آستانه payout در Ocean: عدد 0.01048576 BTC از بررسی‌های ثانویه به‌دست آمده و به‌طور مستقیم توسط مستندات رسمی تأیید نشده است.
5. hashprice زنده دقیق در تاریخ انتشار. خواندن عدد مستقیماً از شاخص Luxor کار نکرد: صفحه از طریق script رندر می‌شود و cache مقادیری را ارائه می‌دهد که به‌وضوح قدیمی هستند. طبق بازنشرهای مورخ داده Hashrate Index برای 2026-09-05 و 2026-09-08، hashprice حدود 39 تا 40 USD به ازای هر PH/s در روز بوده، یعنی تقریباً 0.039 تا 0.040 USD به ازای هر TH/s. یک بررسی مورخ 2026-09-06 آن را در میانه سی‌ها قرار می‌دهد، که با سه منبع دیگر هم‌خوانی ندارد. این برای جهت‌گیری کافی است، اما برای یک محاسبه shutdown، خودتان مقدار را در روزی که محاسبات را انجام می‌دهید بررسی کنید. برای زمینه، طبق بررسی‌های ماهانه منتشرشده Luxor، کف شش‌ماهه 27.74 USD به ازای هر PH/s در روز در تاریخ 2026-06-06 و سقف آن 40.02 USD در تاریخ 2026-08-27 است.

نسخه کوتاه

بلاک‌ها، fee های داخل آن‌ها، تراکنش‌های payout و hashrate خود شما قابل تأیید هستند. جزئیات داخلی یک پنجره PPLNS و ظرفیت واقعی یک pool قابل تأیید نیستند، و block share در explorer فقط یک نماینده برای دومی است.

انتظار خود را بر اساس پارامترهای شبکه برای هر تاریخ محاسبه کنید، نه یک snapshot یک‌ماهه. در FPPS، خط credit باید ثابت باشد، در PPLNS در طول یک فصل قضاوت کنید، و در FPPS، luck هیچ ربطی به payout شما ندارد.

ابتدا پول گمشده را در کسورات جستجو کنید. آستانه‌ها، کارمزدهای شبکه، حداقل‌های جداگانه withdrawal و spread های تبدیل بیشتر موارد "کمتر از انتظار رسیده" را توضیح می‌دهند. فقط زمانی که یک شکاف پس از 30 روز و یک محاسبه مجدد باقی بماند باید یک تیکت باز کنید، و آن را همراه با یک جدول باز کنید.