Майнинг табысын қалай салыстыру керек: pool, wallet және BTC сату жазбалары

Майнинг табысы pool dashboard-та көрінген саннан аяқталмайды. Share сыйақысы balance-қа өтеді, payout жасалады, on-chain расталады, wallet-қа түседі, кейін сатылуы мүмкін. Әр кезеңнің уақыты мен бірлігі бөлек; дұрыс reconciliation осы тізбекті үзбей байланыстырады.

Дерек 2026-08-09 күні тексерілді. Pool export, салық нысаны және есеп саясаты өзгеруі мүмкін; ресми KGD/Adilet материалын және кәсіби есеп пікірін қайта тексеріңіз.

Мазмұны

Бірліктер мен уақытты бекітіңіз
Төрт ledger
Pool-дан wallet-қа
Wallet roll-forward
BTC сатылымына дейін
Exception queue
Айлық close pack
Form 880 және ресми дерек
Бастапқы дерек келісімін бекітіңіз
Кірісті ай соңында қайта ашуға болатын пакетпен жабыңыз
Жиі қойылатын сұрақтар

Бірліктер мен уақытты бекітіңіз

BTC мөлшерін негізгі бірлік ретінде сақтаңыз. KZT бағалау үшін қолданылған timestamp, market source және policy бөлек баған болсын. Pool timezone, blockchain UTC, wallet және банк UTC+5/UTC+6 немесе local time қолдануы мүмкін; бәрін бір RFC3339 уақытқа қалыпқа келтіріңіз, бірақ original timestamp-ты өшірмеңіз.

Күндік cutoff жазылмаса, түнгі payout екі кезеңге түсіп, жалған айырма береді. Month-end-де pending reward, unpaid balance және confirmation жолындағы transaction бөлек көрсетіледі.

Төрт ledger

Pool ledger: worker, accepted hashrate, reward type, fee, credit date, payout ID. Chain ledger: txid, output, fee, block/confirmation. Wallet ledger: address/account, received BTC, internal transfer, closing balance. Sale ledger: platform deposit, order/convert, gross BTC, fee, net KZT, bank receipt.

Жалғаушы кілт ретінде payout ID + txid + amount + уақыт терезесі қолданылады. Txid бір payout-та бірнеше output қамтуы мүмкін; address бойынша ғана сәйкестендіру жеткіліксіз.

Pool-дан wallet-қа

күтілетін payout = opening unpaid + credited rewards − pool fee − closing unpaid. Оны payout export-пен салыстырыңыз. Содан кейін txid output-тарының wallet-тағы түсуін тексеріңіз. Braiins account құжаты rewards, payouts және activities-ті CSV/JSON экспорттау мүмкіндігін көрсетеді.

Айырма payout minimum, кейінге қалған төлем, correction, transaction fee немесе timezone cutoff болуы мүмкін. «Шамамен тең» деп жабудың орнына reason code беріңіз.

Wallet roll-forward

closing BTC = opening BTC + external receipts − external sends − network fee ± internal-classification adjustments. Internal wallet transfer табыс немесе шығын емес; екі жақта бір transfer ID арқылы жойылады.

Address discovery толық болмаса, wallet balance chain explorer-ден өзгеше көрінуі мүмкін. Privacy үшін операциялық address-ті жарияламаңыз; reconciliation жүйесі read-only бақылау мен access control қолдансын.

BTC сатылымына дейін

Wallet send txid platform deposit-пен, deposit сатылым order-мен, order bank receipt-пен байланысады. Gross BTC, trading/convert fee, withdrawal/bank fee, spread және net KZT бөлек. Бір ғана KZT түсуін «BTC revenue» деп жазу fee мен timing-ті жасырады.

Miner production revenue, BTC holding gain/loss және conversion cost-ты басқарушылық есепте бөлек көрсетіңіз. Заңдық/салықтық жіктеуді жергілікті кәсіби маман бекітеді.

Exception queue

Автоматты немесе қолмен салыстырылмаған жол queue-ға түседі: missing txid, duplicate payout ID, amount tolerance, unknown address, delayed bank receipt, reversed trade. Әр exception owner, due date, evidence және resolution code алады.

Materiality шегі ұсақ айырманы басқарады, бірақ белгісіз address немесе duplicate ешқашан жай ғана materiality-мен жабылмайды. Қауіпсіздік сипаты бар exception дереу incident response-қа беріледі.

Айлық close pack

Pool opening/closing balance, credited BTC, payout BTC, wallet roll-forward, platform balance, sold BTC, net KZT және unresolved exception бірге бекітіледі. Export file hash немесе өзгермейтін archive, алынған күні және source account сақталады.

Reviewer preparer-ден бөлек болуы тиіс. Close аяқталған соң period lock жасалады; кейінгі correction жаңа journal entry және audit trail арқылы кіреді.

Form 880 және ресми дерек

Қазақстан KGD материалдары digital mining receipts және form 880.00 жөніндегі ресми ақпарат береді. Қай өріс пен кезең нақты субъектіңізге қолданылатынын ағымдағы taxpayer cabinet және Tax Code бойынша растаңыз. Мақала нысанды толтыру бойынша ойдан шығарылған қадам бермейді.

Жиі қойылатын сұрақтар

Dashboard balance бухгалтерлік дәлел ме?

Жалғыз өзі жеткіліксіз; export, payout ID, txid, wallet және банк тізбегі керек.

Internal transfer табыс па?

Жоқ, егер бір ұйымның wallet-тары арасында болса; екі жақ сәйкестендіріледі.

Айырманы қашан жабуға болады?

Себебі, evidence, owner және approval болғанда; белгісіз address қауіпсіздік оқиғасы ретінде қаралады.

Бастапқы дерек келісімін бекітіңіз

Дұрыс reconciliation ең әуелі қай файл «шындық көзі» екенін анықтаудан басталады. Pool dashboard-тағы экран, CSV export және API нәтижесі бір күнде әртүрлі болуы мүмкін: уақыт белдеуі, pending reward, кейінгі correction немесе интерфейстің дөңгелектеуі әсер етеді. Сондықтан әр дерек көзі үшін атау, иесі, экспорт форматы, уақыт белдеуі, валюталық бірлік, алынған уақыт және өзгермейтін архив орны жазылған source-data contract жасаңыз.

Айлық close кезінде қолданылатын raw файлды өңдемеңіз. Оны checksum немесе қолжетімді басқа тұтастық белгісімен архивтеп, талдау үшін бөлек working copy жасаңыз. Файлды кім жүктегені мен қашан жүктегені көрінуі керек. Кейін pool correction енгізсе, ескі файлды үстінен алмастырмай, жаңа нұсқаны бөлек сақтаңыз және айырмасын reconciliation adjustment ретінде көрсетіңіз.

Кемінде мына деректер бөлек сақталсын:

worker деңгейіндегі hashrate және accepted/rejected share тарихы;
reward ledger және оның күйі: есептелген, payable, төленген немесе түзетілген;
payout тізімі, txid, комиссия және destination address;
өз wallet-тарыңыздың транзакция экспорты;
exchange deposit, trade және withdrawal жазбалары;
банкке түскен сома мен банк комиссиясы;
электр есептегіші, downtime және asset cohort журналы.

Скриншот түсініктеме үшін пайдалы, бірақ негізгі бухгалтерлік дәлелдің орнына жүрмейді. Экспортталатын CSV немесе JSON бар болса, ай соңындағы нұсқасын сақтаңыз; Braiins аккаунт құжаттамасы payout, reward және activity тарихын экспорттау мүмкіндігін көрсетеді. Платформа форматы өзгерсе, импорт ережесін үнсіз түзетпей, schema change ретінде тіркеңіз.

Cut-off күнтізбесін бірдей қолданыңыз

Pool, blockchain, exchange және банк әртүрлі уақытпен есеп жүргізеді. Бір жүйе UTC, екіншісі Астана уақыты, үшіншісі payout cycle бойынша күнді жабуы мүмкін. Айдың соңғы минутында табылған reward сол айдың өндірісі болғанымен, wallet-қа келесі айда түсуі ықтимал. Осыны «жоғалған BTC» деп санау да, келесі айда қайта кіріс ету де қате.

Close policy үш уақытты ажыратсын: өндіріс уақыты, pool reward-ты мойындаған уақыт және on-chain payout уақыты. Сату үшін тағы trade execution, exchange settlement және банктік credit уақыты қосылады. Басқарушылық есепте қайсысы қолданылатыны анық жазылсын; салықтық және бухгалтерлік жіктеуді жергілікті кәсіби кеңесшімен бекітіңіз.

Cut-off тесті үшін айдың соңғы екі күні мен келесі айдың алғашқы екі күніндегі ірі жазбаларды қолмен қараңыз. Reward алдыңғы айда есептеліп, payout келесі айда келсе, payable bridge арқылы байланыстырылсын. Exchange-та сауда орындалып, банк төлемі кешіксе, receivable немесе settlement-in-transit ретінде белгіленсін. Бір транзакция екі кезеңге кіріп кетпеуі керек.

Worker-ді asset cohort-пен байланыстырыңыз

Worker атауы өзгерсе немесе бір майнер басқа rack-ке көшсе, pool табысын нақты құрылғы шығынымен салыстыру қиындайды. Worker naming convention asset ID, сайт және cohort-ты тұрақты байланыстыратындай болсын. Құрылғы ауыстырылғанда ескі worker тарихын жоймай, effective-from және effective-to күндері бар mapping кестесін жаңартыңыз.

Mapping кемінде мына сұрақтарға жауап беруі тиіс:

белгілі бір күні worker-ге қай ASIC жұмыс істеді;
ол қай электр есептегішінің шекарасына кірді;
қандай firmware және қуат профилі қолданылды;
planned немесе unplanned downtime болды ма;
сол cohort-тың жөндеу және cooling шығыны қандай;
pool ауысқан кезде ескі және жаңа worker қалай байланыстырылды.

Күнделікті барлық worker-ді қолмен тексеру қажет емес. Бірақ нөлдік табыс, қалыптан тыс reject, атауы белгісіз worker және cohort орташа мәнінен қатты ауытқыған құрылғы exception queue-ға түссін. Бұл табысты ғана емес, ұрланған credential немесе бұрылған pool конфигурациясын да ерте көрсетуі мүмкін.

Reward күйін payout-пен шатастырмаңыз

PPS, FPPS немесе PPLNS тәрізді есептеу әдістері reward-тың пайда болу логикасын өзгертеді. Dashboard-та көрінген барлық сан бірден wallet-та жұмсауға дайын BTC емес. Әр pool үшін reward state diagram жасаңыз: estimated, confirmed, payable, paid және correction секілді нақты күй атауларын сол платформаның құжаттамасымен сәйкестендіріңіз.

Айлық bridge қарапайым формуламен тексеріледі:

Бастапқы төленбеген reward + кезеңде есептелген reward - payout - correction = соңғы төленбеген reward

Бұл формуладағы әр жол бірдей бірлікте және бірдей cut-off-пен есептелуі тиіс. Pool fee немесе transaction fee reward-тан алдын ала шегерілсе, gross және net соманы араластырмаңыз. Платформа комиссия ережесін өзгертуі мүмкін, сондықтан пайызды мақаладағы тұрақты саннан емес, close күні сақталған ресми ереже мен account export-тан алыңыз.

Variance шықса, ең алдымен дөңгелектеу, minimum payout, payout schedule, orphan/stale share correction және уақыт белдеуін тексеріңіз. Айырманы бірден «басқа шығыс» ретінде жауып тастау кейінгі алаяқтық немесе интеграция қатесін жасырады.

On-chain payout-ты дәл сәйкестендіріңіз

Pool payout жолындағы txid blockchain жазбасына апаруы тиіс. Бірақ бір transaction бірнеше алушыға төлем жасай алады, сондықтан transaction total-ды өз кірісіңіз деп алуға болмайды. Destination address, сізге тиесілі output, алынған сома және confirmation күйі арқылы сәйкестендіріңіз. Address ұйымның wallet registry-сінде болуы керек.

Wallet registry әр address үшін иесін, мақсатын, custody түрін, ашылған және жабылған күнін көрсетсін. Жаңа address қосылса, екі адамның тексеруі және test transfer дәлелі қажет. Pool payout address өзгерсе, бұл жоғары тәуекелді өзгеріс: change ticket, тәуелсіз мақұлдау және кейінгі алғашқы payout бақылауы болсын.

Кейбір wallet интерфейсі internal transfer немесе change output-ты сыртқы кіріс сияқты көрсетуі мүмкін. Wallet roll-forward кезінде ұйым ішіндегі address-тер арасындағы қозғалысты табысқа қоспаңыз. Формула:

Бастапқы BTC + сыртқы кіріс - сыртқы шығыс - network fee = соңғы BTC

Ұйым ішіндегі қозғалыс екі жағынан да жойылады. Confirmation күтіліп тұрған payout бөлек in-transit тізімінде қалсын; оны жоғалған деп есептемеңіз, бірақ ұзақ уақыт расталмаса exception owner тағайындаңыз.

Exchange пен банкке дейінгі тізбекті жабыңыз

BTC exchange-ке түскенде reconciliation аяқталмайды. Deposit txid, credited amount, trade order, executed quantity, price, trading fee, fiat balance, withdrawal және банкке түскен net сома бір chain ID арқылы байланыссын. Бірнеше шағын trade бір банктік төлемге біріктірілсе, allocation кестесі қажет.

Әр сату пакеті үшін:

source wallet және шығу txid;
exchange deposit reference;
сатылған BTC және қалған BTC;
order ID және execution уақыты;
gross fiat, trading fee және net fiat;
fiat withdrawal reference;
банк statement жолы мен банк комиссиясы;
келісілген бағам көзі және бағалау уақыты жазылсын.

Платформа көрсететін уақытша fee немесе төлем әдісін тұрақты болжамға айналдырмаңыз. Close кезінде нақты account statement пен ресми terms-ті сақтаңыз. Егер exchange statement банк сомасымен сәйкес келмесе, айырманы FX, комиссия, pending settlement немесе үшінші тарап төлемі бойынша бөлек жіктеңіз.

Бағалау саясатын алдын ала бекітіңіз

BTC өндірісі, wallet-қа түсуі және сатылуы әртүрлі бағамен болуы мүмкін. Басқарушылық талдау үшін қай сәттің бағамы қолданылатынын алдын ала анықтаңыз: reward recognition, payout receipt немесе sale execution. Бір кезеңде әдісті өзгертіп, нәтижені жақсы көрсетуге болмайды. Әдіс өзгерсе, себебі, әсері және салыстырмалы көрсеткіш ашық жазылсын.

Бұл бөлім салық кеңесі емес. KZT бағалау, кірісті тану және digital mining fee есептілігі бойынша қолданыстағы Қазақстан талаптарын бухгалтер мен заңгер тексеруі керек. Ішкі саясаттың мақсаты — барлық айда бірдей дерек қолдану және кейін дәлелді қайта құру.

Бағам көзі үшін ресми немесе тексерілетін нарық дерегін таңдаңыз. Timestamp, currency pair және timezone сақталсын. Күндік орташа баға қолданылса, формуласы құжатталсын; нақты trade price бар сату операциясына орташа бағаны байқамай алмастырмаңыз.

Fee-ді дұрыс объектіге бекітіңіз

Pool fee, network fee, exchange trading fee, fiat withdrawal fee және банк комиссиясы — бес түрлі шығыс. Оларды бір «комиссия» жолына жинасаңыз, қай кезеңнің қымбаттағанын көре алмайсыз. Fee taxonomy жасап, әр жазбаны нақты транзакцияға, payout-қа немесе сату пакетіне байланыстырыңыз.

Network fee ұйым ішіндегі consolidation кезінде шықса, оны өндіріс кірісінен автоматты шегерудің орнына custody операциясына жатқызыңыз. Exchange fee BTC-мен алынған болса, BTC quantity roll-forward пен fiat P&L екеуіне әсерін келісілген әдіспен көрсетіңіз. Pool fee gross reward export-та мүлдем көрінбесе, net reward-ты gross деп қайта есептемеңіз.

Ай сайын fee rate емес, абсолют сома мен BTC бірлігіне шаққандағы шығынды салыстырыңыз. Rate өзгермесе де ұсақ payout немесе жиі withdrawal абсолют шығынды арттыруы мүмкін.

Matching ережесі мен tolerance-ті басқарыңыз

Автоматты matching уақыт үнемдейді, бірақ ережесі көрінбесе қателікті жылдам көбейтеді. Exact match алдымен txid, address, asset және amount арқылы орындалсын. Уақыт немесе дөңгелектеу tolerance-і тек нақты түсіндірілген жағдайға қолданылады. «Сома шамамен ұқсас» деген ереже екі төлемді қате біріктіруі мүмкін.

Әр matching rule үшін нұсқа, иесі, тест жиыны және өзгеріс күні болсын. Ереже жаңарғанда өткен жабық кезеңге автоматты түрде қайта қолданбаңыз. Exception rate кенет азайса, бұл процесс жақсарды деген сөз емес; ереже тым кең болып, айырманы жасыруы мүмкін.

Үлгілік бақылау ретінде ай сайын автоматты matched жазбалардың кездейсоқ бөлігін қолмен blockchain, pool және bank деректерімен тексеріңіз. Жалған match табылса, әсер еткен барлық кезең мен жазбаны scope review-ға қосыңыз.

Exception queue-ды сомамен және жасымен басқарыңыз

Exception тек тізім емес, шешім кезегі болуы керек. Әр айырмада source, amount, BTC/KZT әсері, ашылған күн, ықтимал себеп, иесі және келесі әрекет бар. Priority сомаға ғана тәуелді болмасын: payout address өзгерісі шағын сомада да жоғары қауіпке ие.

Age bucket қолданыңыз: 0–2 күн, 3–7 күн, 8–30 күн және 30 күннен көп. Ескі айырманы жаңа айдың «miscellaneous» жолына көшіру жабу емес. 30 күннен асқан exception басшылыққа және қаржы иесіне escalation алсын. Қате түзетілсе, original entry жоғалмай, correction reference-пен байланыстырылсын.

Close sign-off кезінде ашық exception-дардың жиынтық әсері көрсетілсін. Materiality шегінен төмен болса да, қайталанатын бірдей қате control weakness ретінде бөлек қаралады.

Айлық close-ты кезеңмен құлыптаңыз

Close checklist жауапкершілікті бөледі. Бір адам raw export жинайды, екіншісі mapping пен matching-ті орындайды, үшіншісі exception мен final roll-forward-ты тексереді. Шағын командада толық бөлу мүмкін болмаса, кемінде wallet address өзгерісі, manual adjustment және bank settlement тәуелсіз review алсын.

Close реті:

барлық source export-ты timestamp-пен архивтеу;
worker-to-asset mapping толықтығын тексеру;
reward-to-payout bridge жасау;
payout-ты on-chain және wallet-пен сәйкестендіру;
exchange пен bank settlement-ті жабу;
fee мен FX allocation-ды тексеру;
exception aging және materiality review;
энергия, downtime және BTC өндірісінің басқарушылық салыстыруы;
reviewer sign-off және period lock.

Period lock-тен кейінгі өзгеріс тек correction journal арқылы жасалсын. Кім, не үшін, қай дерекке сүйеніп өзгерткені және алдыңғы есепке әсері көрінуі керек. Ескі файлды үнсіз ауыстыру audit trail-ды жояды.

Қауіпсіздік белгісін қаржы айырмасынан ажыратпаңыз

Reconciliation кейде киберқауіпсіздік оқиғасын бірінші байқайды. Reward қалыпты болғанымен payout басқа address-ке кетсе, worker атауы өзгерсе немесе exchange deposit әдеттегі wallet-тан келмесе, мәселені тек қаржы командасына қалдырмаңыз. Incident playbook іске қосылып, credential, pool конфигурациясы және change log бірге тексерілсін.

Күдікті жағдайда дәлелді сақтаңыз: raw export, txid, address history, login журнал және change ticket. Барлық парольді асығыс ауыстырмас бұрын scope пен журналды сақтау қажет, бірақ активті жоғалту қаупі болса қауіпсіздік иесі жедел оқшаулау шешімін қабылдайды. Түзету аяқталған соң reconciliation қайта орындалып, жоғалған немесе бұрылған соманың нақты әсері бекітіледі.

Басшылыққа шешім беретін reconciliation жасаңыз

Таза математикалық теңдік жеткіліксіз. Айлық пакет BTC өндірісі неге өзгергенін түсіндіруі тиіс: network difficulty, uptime, hashrate, pool luck немесе әдіс, fee, cooling derating және сату уақыты. Себептер дерекпен бөлінбесе, басқарушы бағаның өзгерісін операциялық өнімділікпен шатастырады.

Қорытынды кестеде кемінде өндірілген BTC, төленбеген reward, wallet-қа түскен BTC, сатылған BTC, соңғы BTC қалдығы, барлық fee, KZT түсімі және ашық exception көрсетілсін. Әр KPI-дың бастапқы файлына дейінгі сілтемесі болсын. Сонда reconciliation тек есеп беру емес, pool таңдау, payout жиілігі, custody және сату жоспары бойынша шешім құралына айналады.

Кірісті ай соңында қайта ашуға болатын пакетпен жабыңыз

Revenue reconciliation аяқталды деу үшін pool панеліндегі сан мен wallet кірісі тең болуы жеткіліксіз. Айлық close пакетінде бастапқы pool export, API сұрауының уақыты, worker mapping, reward түрі, fee, payout transaction, wallet бақылауы, exchange депозиті және банкке дейінгі сатылым болса оның есеп айырысуы байланысуы керек. Әр файлдың бастапқы нұсқасы сақталып, кейінгі өңдеу бөлек жұмыс кітабында жасалады.

Экспорттың толықтығын тексеріңіз: ең ерте және соңғы timestamp есептік кезеңді жаба ма, pagination барлық жолды алды ма, time zone бірдей ме, inactive worker жоғалып кетпеді ме. API өзгерсе немесе баған атауы ауысса, импорт скрипті үнсіз нөл бермеуі тиіс. Қатар саны мен бақылау сомасы алдыңғы аймен салыстырылып, күтпеген айырма exception ретінде ашылады.

Close package-ке preparer, reviewer және approval уақыты қосылады. Reviewer тек формуланы емес, бастапқы файлға дейін кемінде бірнеше материалдық жолды қайта орындайды. Түзету болса, бұрынғы нұсқа өшірілмейді; correction entry себебі, сомасы және бекітуі журналда қалады.

Worker-ден бухгалтерлік cohort-қа дейін mapping ұстаңыз

Pool worker атауы asset register-дегі сериялық нөмірге, site/rack орнына, ASIC моделіне және қаржылық owner-ға байланыстырылсын. Құрылғы ауысқанда worker атауын қайта қолдану тарихи табысты жаңа asset-ке қате жүктеуі мүмкін. Сондықтан mapping-те effective-from және effective-to уақыты болсын.

Hosting клиенттері немесе әртүрлі заңды тұлғалар бір pool account қолданса, payout-ты жай hashrate үлесімен бөлу жеткіліксіз. Accepted shares, fee plan, downtime және cutoff бірдей әдіспен есептелуі керек. Contract қандай бөлу әдісін талап етсе, reconciliation соны қайталайды; қаржыға ыңғайлы басқа формула қолданылмайды.

Unknown worker автоматты түрде «басқа» жолына түспесін. Ол quarantined exception болып, owner анықталғанша табыс бөлінбейді. Белгісіз worker credential ұрланғанын, қате конфигурацияны немесе жаңа asset-тің тіркелмегенін көрсетуі мүмкін.

Reward accrual мен нақты payout-ты бөлек көрсетіңіз

PPS, PPLNS немесе басқа әдісте күндік estimated reward нақты төленген BTC-мен бір уақытқа түспеуі мүмкін. Accrual bridge кезең басындағы төленбеген балансқа жаңа reward-ты қосып, fee мен adjustment-ты алып, payout пен кезең соңындағы қалдыққа жеткізеді. Бұл формула pool әдісіне және statement өрістеріне сай құжатталады.

Pool «bonus», transaction fee share, merged mining немесе manual adjustment көрсетсе, әрқайсын тұрақты mining revenue-ға қоспай бөлек code беріңіз. Бір реттік credit тұрақты yield-ты жасанды жақсартады. Negative adjustment та жасырылмайды; себебі мен қатысты кезең белгіленеді.

Estimated dashboard санын бухгалтерлік бастапқы құжат ретінде пайдаланбаңыз, егер pool кейін final есеп берсе. Close күні finalization аяқталмаған болса, accrual саясаты мен кейінгі true-up тәртібі бекітіледі. Келесі айдағы түзетудің қай кезеңге жататыны түсінікті болсын.

On-chain қозғалысты transaction деңгейінде сәйкестендіріңіз

Әр payout үшін txid, network, destination address, amount, fee handling және confirmation status сақталады. Wallet address inventory payout адресінің сол кезеңде мақұлданғанын дәлелдейді. Адрес ауысса, change ticket пен тәуелсіз verification қажет; тек pool email-іне сену жеткіліксіз.

Wallet-ке түскен сома pool statement-тен өзгеше болса, minimum payout, network fee, internal transfer немесе бірнеше күннің бірігуін тексеріңіз. Бір transaction бірнеше accrual кезеңін жапса, allocation кестесі жасалады. Transaction explorer скрині көмекші дәлел, негізгі дәлел ретінде machine-readable дерек пен wallet жазбасы сақталғаны дұрыс.

Reorg немесе кеш confirmation сирек болса да, cut-off саясаты оны қамтуы тиіс. Broadcast болған, бірақ жеткілікті confirmation алмаған төлем cash-like balance ретінде танылмайды. Келесі кезеңде статус өзгергенде audit trail жаңартылады.

BTC көлемін fiat бағалауынан ажыратыңыз

Mining production reconciliation алдымен BTC бірлігінде жабылады. Содан кейін ғана есеп саясатына сай KZT немесе басқа валюта бағасы қолданылады. Бұл екі қадамды араластыру price variance-ті өндіріс variance-і сияқты көрсетеді. Баға көзі, timestamp, market және қолданылған әдіс құжатта көрсетіледі.

Сату кезінде gross BTC, exchange trading fee, withdrawal немесе banking fee және нақты fiat receipt бөлек жолдарда тұрады. «Сатылым бағасы» ретінде order экранындағы quote емес, орындалған trades пен түскен net қаражат қолданылады. P2P болса, counterparty төлемі өз банк жазбасымен сәйкестенеді және third-party төлем stop-line-ы орындалады.

Unrealized balance пен сатылған көлемді бөлек ұстаңыз. Айлық пайда жоғары көрінгенімен, сатылмаған BTC баға тәуекелінде қалады; ал cash міндеттемесі KZT-мен төленеді. Treasury панелі келесі төлем күніне дейінгі өтімділікті көрсетсін.

Yield variance-ті бақыланатын себептерге бөліңіз

Expected BTC моделін нақты accepted hashrate, network difficulty, pool method және уақытпен құрыңыз. Айырманы кемінде uptime, reject, hashrate efficiency, fee, luck және cutoff санаттарына бөліңіз. «Pool luck» түсіндірмесі қалдық ретінде ғана қолданылсын; техникалық себептер өлшенбей тұрып бәрін luck-қа жаппаңыз.

Cohort деңгейінде бірдей модельдерді салыстырыңыз. Бір rack-та yield төмен болса, firmware, температура, network latency немесе worker mapping тексеріледі. Бүкіл site бірдей төмендесе, difficulty, pool есептеу немесе жалпы байланыс ықтимал. Салыстыру терезесі жеткілікті ұзақ болуы керек, бірақ incident-ті жасыратындай айлық орташаға ғана сүйенбеңіз.

Materiality шегін BTC және KZT түрінде бекітіңіз. Шектен асқан variance owner, due date және evidence талабымен exception register-ге түседі. Ескі exception келесі айға үнсіз көшірілмейді; status пен aging басшылыққа көрінеді.

Pool немесе wallet ауысуын parallel бақылаумен орындаңыз

Миграция алдында екі жүйенің cutoff, payout minimum, fee және worker атау ережесін салыстырыңыз. Шағын cohort-ты parallel test-ке жіберіп, accepted yield мен payout latency-ді бірдей уақыт аралығында өлшеңіз. Network difficulty өзгерісін елемей, екі күннің абсолют BTC санын салыстыру қате қорытынды береді.

Ауыстыру кезінде ескі pool-дағы төленбеген қалдық жоғалмауы керек. Final payout немесе recovery тәртібі, аккаунтқа қолжетімділік және statement сақтау мерзімі exit checklist-ке кіреді. API кілті мен worker credential қажет болмай қалғанда жойылады.

Wallet ауысқанда address allowlist, тест транзакция және тәуелсіз растау орындалады. Бірінші толық payout түскенше ескі адреске қолжетімділік бақыланады, бірақ рұқсатсыз қайта қолдануға жол берілмейді. Migration close екі жақтың балансын нөл немесе дәлелденген қалдыққа жеткізеді.

Басшылыққа арналған reconciliation бақылауларын бекітіңіз

Айлық панельде produced BTC, accrued BTC, paid BTC, wallet-confirmed BTC, sold BTC және closing BTC бір көпірде көрінеді. Әр кезеңнің fee-і бөлек көрсетіледі. Көпір нөлге жабылмаса, close мәртебесі «шартты» болып, айырма мен owner көрсетіледі.

Негізгі бақылаулар: белгісіз worker саны нөл, мақұлданбаған payout адресі нөл, ескірген exception белгіленген шектен аспайды және material variance review-сыз жабылмайды. Бақылау «орындалды» деген checkbox емес; файл, transaction немесе review жазбасына сілтейді.

Тоқтату шартын алдын ала анықтаңыз. Payout адресі күтпеген жерден өзгерсе, pool export толық болмаса немесе wallet пен statement арасында түсіндірілмейтін материалдық айырма болса, BTC сатуға және айлық нәтижені бекітуге уақытша тыйым салынады. Бұл тәртіп табыс санын әдемі көрсету емес, өндіруден банкке дейінгі әр қозғалысты қайта есептеуге мүмкіндік береді.