Өндірілген BTC-ді бөліп сату жоспары

Майнер үшін BTC сату жоспары бағаны дәл табу әрекеті емес. Оның міндеті — электр, жалақы, hosting, жөндеу және салықтық міндеттемелерді мерзімінде төлеу үшін жеткілікті KZT өтімділігін қамтамасыз ету, ал қалған BTC бойынша шешімді саналы түрде бөлек қабылдау.

Дерек 2026-08-09 күні тексерілді. AFSA public register арқылы платформа рұқсатын және мәміле күніндегі fee, limit, KYC және withdrawal шартын қайта тексеріңіз. Бұл инвестициялық немесе салықтық кеңес емес.

Мазмұны

Міндеттемелер күнтізбесінен бастаңыз
BTC-ді үш шелекке бөліңіз
Бөлшектеп сату ережесі
Реттелетін платформаны тексеру
Орындау журналы
Стресс сценарийі
Басқару шектері
Cash-flow болжамын үш уақыт терезесіне бөліңіз
Сату мандатын алдын ала бекітіңіз
Жиі қойылатын сұрақтар

Міндеттемелер күнтізбесінен бастаңыз

Келесі 30, 60 және 90 күндегі KZT төлемдерін тізіңіз: электр, майнингке қолданылатын төлем, hosting/жалдау, жалақы, жөндеу, қарыз, салықтық резерв. Әрқайсына соңғы төлем күні, сенімділік дәрежесі және кешіккендегі салдар жазылады.

сатуға қажетті BTC = (міндеттеме KZT + қауіпсіздік резерві − қолдағы KZT) / консервативті таза BTC бағасы. Таза баға — экрандағы котировка емес; spread, trading/convert fee, withdrawal немесе банк шығыны және slippage шегерілген мән.

BTC-ді үш шелекке бөліңіз

Операциялық шелек жақын шоттарға арналған және баға тәуекеліне ұшырамауы керек. Резерв шелегі жөндеу мен күтпеген downtime-ды өтейді; көлемі тарихи шығынға және lead time-ға негізделеді. Ұзақ мерзімді шелек тек міндеттемелер мен резерв жабылғаннан кейін қалады.

Бұл бөлу wallet архитектурасымен бірдей болуы міндетті емес, бірақ есепте әр BTC бір мақсатқа ғана тағайындалуы керек. Бір баланс бір уақытта әрі электр ақшасы, әрі ұзақ мерзімді инвестиция деп саналса, өтімділік жалған көрінеді.

Бөлшектеп сату ережесі

Күндізгі бағаны қуаламай, төлем мерзіміне байланысты транш белгілеңіз. Мысалы, шоттан 14, 7 және 2 күн бұрын қажетті соманың бөліктерін сату; нақты пайызды өз өтімділігіңізге қарай бекітіңіз. Транш көлемі, ең ерте/соңғы уақыт, рұқсат етілген платформа және жауапты адам жазылады.

Егер баға төмендесе жоспар тоқтамауы тиіс: міндетті төлем үшін stop-loss емес, liquidity rule жұмыс істейді. Баға көтерілсе де келесі екі есепті жабатын KZT резервін қайта BTC-ге толық салмаңыз.

Реттелетін платформаны тексеру

AFSA-ның «Check if a firm is authorised» нұсқауы және DASP public register лицензия мәртебесін тікелей тексеруге арналған. Компания атауы, лицензия нөмірі, status және permitted activities сәйкес болсын. Ескі мақала немесе бренд логотипі белсенді рұқсаттың орнына жүрмейді.

Аккаунтта KYC аяқталғанын, заңды тұлға/жеке тұлға мәртебесін, deposit network, memo/tag қажет пе, күндік limit және банк алу арнасын алдын ала тексеріңіз. Алғашқы аударымды шағын тестпен бастаңыз; адрес пен network-ті екі адамдық бақылаумен растау ірі ферма үшін орынды.

Орындау журналы

Әр сатылымға pool payout ID, wallet txid, платформа deposit ID, сатылған BTC, gross KZT, fee/spread, net KZT, банкке түскен уақыт және қай міндеттемені жапқаны тіркеледі. Бұл кейін revenue reconciliation мен салықтық дәлелге қажет.

Экран суретін жалғыз дәлел етпеңіз. CSV/PDF statement, blockchain txid, банк көшірмесі және internal approval бірге сақталсын. Деректерде аккаунт, email, token және internal URL сыртқа жарияланбайды.

Стресс сценарийі

Баға −20%, payout 48 сағат кешігеді, bank withdrawal уақытша тоқтайды деген үш оқиғаны бірге сынаңыз. Қанша KZT reserve керек және ең соңғы қауіпсіз сату күні қайсы? Екінші рұқсат етілген шығу арнасы бар ма? Ол алдын ала KYC және шағын тесттен өткен бе?

Егер міндеттеме бір платформаға, бір банкке немесе бір күнгі бағаға толық тәуелді болса, бұл concentration risk. Оны «баға көтеріледі» деген болжаммен жабуға болмайды.

Басқару шектері

Алдағы 30 күн KZT coverage 1,0-ден төмендесе, операциялық BTC сатылымы автоматты қаралады. Coverage 1,5-тен асса, артық соманың мақсаты қайта бекітіледі. Нақты коэффициентті бизнес тәуекелі мен шарттарға сай бекітіңіз.

Жоспар ай сайын емес, әр үлкен difficulty өзгерісі, electricity invoice, withdrawal шектеуі немесе лицензия мәртебесі өзгергенде жаңартылады.

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

Барлық өндірілген BTC-ді бірден сату керек пе?

Әмбебап жауап жоқ. Алдымен міндеттеме мен резервті жабыңыз, қалған бөлікке жеке саясат қолданыңыз.

Лимит ордерін қолдану жеткілікті ме?

Жоқ. Өтімділік мерзімі орындалмаған ордерден маңызды; орындалу және fallback ережесі керек.

Лицензияны қайдан тексереміз?

AFSA public register-ден, мәміле алдында нақты заңды тұлға мен permitted activities бойынша.

Cash-flow болжамын үш уақыт терезесіне бөліңіз

30/60/90 күндік жалпы кесте жеткіліксіз болса, күнделікті, апталық және айлық терезе жасаңыз. Күнделікті терезе келесі bank cut-off пен электр авансын, апталық терезе pool payout және жалақыны, айлық терезе салықтық резерв, жөндеу және hosting міндеттемесін көрсетеді. Бір төлемді екі терезеде қайталап қоспау үшін әр міндеттемеге бір ID беріледі.

Әр жолдың үш сомасы болсын: contract/invoice сомасы, ең ықтимал сома және stress сома. Invoice әлі келмесе, алдыңғы айды көшіріп қана қоймай, consumption, тариф және жұмыс күнін бөлек негіздеңіз. Белгісіз міндеттемені нөл деп есептеу өтімділікті артық көрсетеді; ол диапазон немесе жоғары резерв ретінде қалады.

Қолдағы KZT-ны да қолжетімділік бойынша бөліңіз. Bank balance, касса, ұсталған депозит, VAT/tax үшін бөлінген қаражат және еркін резерв бірдей ақша емес. Тек төлем күніне дейін заңды әрі нақты қолжетімді қаражат coverage формуласына кіреді.

Өндірілген BTC-ні cohort бойынша белгілеңіз

Pool-дан түскен әр payout-қа өндіріс кезеңі, pool, wallet address, txid, BTC көлемі және сол кезеңнің есептік шығыны байланыстырылсын. FIFO, weighted average немесе басқа accounting әдісін салық маманымен бекітіңіз; мақала әмбебап салық әдісін ұсынбайды. Маңыздысы — әдіс кезең арасында өз бетімен ауыспауы.

Операциялық, резерв және ұзақ мерзімді bucket бухгалтерлік label арқылы ажыратылады. Wallet-та физикалық бөлуге болады, бірақ міндетті емес; әр сатылған satoshi қай bucket-тен шыққаны анық болуы керек. Резерв BTC-ін уақытша операциялық деп алып, кейін қағаз жүзінде орнына қою double counting тудырады.

Өндірістің өзін forecast-пен араластырмаңыз. Pool pending balance әлі wallet-тағы BTC емес, ал wallet-тағы BTC әлі сатылып KZT-ға түскен ақша емес. Forecast кезеңдері: earned estimate, pool confirmed, on-chain received, platform credited, trade executed, bank settled. Әр кезеңге бөлек confidence беріледі.

Net execution price-ты дұрыс есептеу

Мәміле нәтижесі экрандағы last price-пен өлшенбейді. Бір транш үшін:

net KZT per BTC = bank-ке нақты түскен KZT / сатылған BTC.

Айырманы trading/convert fee, spread, slippage, deposit/withdrawal fee, bank fee және валюталық conversion бөлігіне ажыратыңыз. Кейбір шығын жеке жолда көрінбейді, bid/ask айырмасына кіреді; сондықтан order time reference quote және нақты fill сақталады.

Платформаларды advertised fee бойынша емес, бірдей сценарийдегі net result бойынша салыстырыңыз. Шағын controlled test бір уақытта, ұқсас көлеммен және бірдей bank destination-мен жүргізіледі. Нәтиже лицензия, withdrawal сенімділігі, limit және операциялық тәуекелмен бірге қаралады; ең жоғары net price жалғыз шешім емес.

Транш ережесін баға болжамынан ажырату

Әр bucket үшін trigger бөлек болсын. Операциялық bucket төлем мерзімі мен coverage-ке тәуелді; резерв bucket policy minimum-нан төмендесе толықтырылады; ұзақ мерзімді bucket тек board-approved rebalance немесе тәуекел лимитімен сатылады. Бір триггердің екіншісіне ауысуына жол бермеңіз.

Мысалы, электр шоты 10 күннен кейін төленеді делік. Coverage stress бағамен 0.8 болса, алғашқы транш дереу; platform settlement мерзімі ескеріліп, екінші транш соңғы қауіпсіз күнге дейін; соңғы бөлік bank credit расталғанға дейін күтпей жоспарланады. Нақты пайыздар бизнеске байланысты, бірақ decision time алдын ала жазылады.

Баға белгілі деңгейге жетпесе орындалмайтын limit order міндетті төлем үшін жалғыз әдіс болмауы керек. Deadline жақындағанда marketable order, OTC немесе басқа алдын ала мақұлданған арнаға ауысу ережесі болады. Бұл нақты өнім ұсыну емес; орындалмай қалған ордердің cash-flow тәуекелін басқару.

Платформа readiness пакеті

Сату күні KYC бастау кеш. Әр мақұлданған venue үшін заңды тұлға, AFSA register нәтижесі мен тексеру күні, permitted activity, account owner, KYC статус, лимит, BTC deposit network, bank withdrawal арнасы, support escalation және соңғы test күні жазылады. Status өзгерсе venue автоматты түрде hold күйіне өтеді.

Account жеке тұлғаға, ал өндіріс заңды тұлғаға тиесілі болса, ownership және source-of-funds мәселесі тууы мүмкін. Контрагент пен бухгалтер операция құрылымын алдын ала тексеруі керек. Басқа адамның аккаунтын немесе банк шотын «тез шығу» үшін қолданбаңыз.

Deposit address тұрақты деп ойламаңыз. Әр транш алдында аккаунт ішінен қайта алып, network-ті салыстырып, address change alert-ін тексеріңіз. Үлкен аударымның алдында шағын test және credit confirmation болуы керек. Memo/tag талап етілсе, ол да екі адаммен тексеріледі.

P2P немесе bank transfer кезінде қаражаттың түсуін тексеру

Мәміле арнасы P2P қолданса, платформаның сол күнгі ресми ережесін оқыңыз. «Paid» белгісі немесе жіберілген чек bank balance-қа нақты түскен қаражатты алмастырмайды. Қаражат толық, дұрыс валютада және келісілген account-қа түскені bank арқылы тәуелсіз тексерілмей BTC босатылмайды.

Үшінші тұлға аты, split payment, артық төлемді басқа account-қа қайтару өтініші немесе platform chat-тен сыртқа шығу талабы exception ретінде тоқтайды. AML/KYC және банк саясатына сай compliance review қажет болуы мүмкін. Жеке дерек пен төлем құжатын мақалада жарияламаңыз.

Bank transfer қайтарылу немесе hold тәуекелі болса, settlement finality шарты операциялық саясатта жазылады. Support-пен тек ресми арнада сөйлесіп, case ID сақтаңыз. Қысым көрсеткен контрагент үшін бақылауды әлсіретпеңіз.

Execution ticket және екі адамдық бақылау

Әр траншқа ticket ашылады: forecast revision, bucket, BTC көлемі, deadline, venue, order type, limit, expected net KZT, destination bank, инициатор және approver. Ticket мақұлданғаннан кейін address немесе көлем өзгерсе, қайта approval керек. Мессенджердегі «иә» толық approval дәлелі емес.

Орындаушы trade fill, platform fee, on-chain txid және withdrawal reference-ті тіркейді. Тексеруші bank credit-ті және net KZT-ны салыстырады. Бір адам әрі quote таңдап, әрі address ауыстырып, әрі reconciliation жаппау керек.

Үлкен транш екі кішірекке бөлінсе, әрқайсысының тәуелсіз fee және settlement әсерін көрсетіңіз. Бөлу slippage-ті азайтуы мүмкін, бірақ бірнеше withdrawal fee немесе операциялық қатені көбейтуі мүмкін. Нәтиже нақты журналмен өлшенеді.

Сатылымнан кейінгі үш жақты reconciliation

Үш дерек жиыны сәйкес болуы керек: blockchain/wallet, platform statement және bank statement. Pool payout-тан platform deposit-ке дейін txid; deposit-тен trade-ке дейін account entry; trade-тен bank credit-ке дейін withdrawal reference байланысады. Бір жүйедегі screenshot екінші жүйені дәлелдемейді.

Күндік close кезінде expected BTC, credited BTC, sold BTC, residual balance, gross KZT, fees және bank-settled KZT тексеріледі. Айырма tolerance-тан асса, ticket жабылмайды. Timing difference, pending confirmation, fee, partial fill немесе қате кезең root cause ретінде белгіленеді.

Бухгалтерлік және салықтық құжатты жергілікті маман бекітеді. Сатылым күні, бағалау әдісі, fee treatment және KZT аудармасы бір саясатпен жүргізіледі. Заң немесе platform statement форматы өзгерсе, policy revision жасалады.

Сценарийлерді бір-бірлеп емес, бірге сынаңыз

Нақты stress-test бірнеше оқиғаны біріктіреді: network fee өсті, pool payout 48 сағат кешікті, BTC бағасы түсті, негізгі platform account review-ға түсті және bank cut-off өтті. Әр сценарийде соңғы қауіпсіз transfer күні, minimum BTC sale, KZT buffer және жауапты адам есептеледі.

Fallback venue бар деген белгі оның дайын екенін дәлелдемейді. Лицензия тексерілген, KYC аяқталған, test deposit және test withdrawal өткен, bank destination қабылданған және access owner қолжетімді болуы керек. Әйтпесе ол қағаздағы мүмкіндік қана.

Егер stress сценарийде жалақы немесе электр кешігетін болса, long-term BTC bucket-ін қысқарту, KZT резервін арттыру немесе invoice мерзімін қайта келісу керек. «Баға қалпына келеді» деген жорамал control емес.

Орындауды тоқтататын жағдайлар

Келесі жағдайда транш орындалмайды немесе эскалацияланады: AFSA мәртебесі тексерілмеген; account owner өндіріс иесімен сәйкес емес; deposit network/address екі рет расталмаған; KYC/limit жеткіліксіз; bank destination белгісіз; price source немесе fee түсініксіз; approver қолжетімсіз; malware күдігі бар; third-party payment сұралған; source-of-funds құжаты дайын емес.

Тоқтау электр төлемін ұмыттыру емес. Incident lead forecast-ты жаңартып, соңғы қауіпсіз күнді есептейді және бұрын мақұлданған fallback арнасын қосады. Егер қауіпсіз арна жоқ болса, бұл алдын ала KZT buffer жеткіліксіз болғанын көрсетеді.

Ай соңында policy effectiveness қараңыз: қанша транш жоспар бойынша өтті, net execution ауытқуы, settlement уақыты, exception саны, қандай control істемеді және coverage ең төмен қанша болды. Келесі айдың tranche көлемі осы дерекпен өзгереді, бағаға қатысты hindsight-пен емес.

Bank cut-off және мереке күнін жоспарға қосыңыз

BTC мәмілесі орындалған уақыт пен KZT-ның төлемге жарамды болып түскен уақыты бірдей емес. Platform processing, bank cut-off, демалыс және мереке күндері settlement-ті кейінге ысыруы мүмкін. Әр міндеттеменің «төлем күнімен» бірге «қаражат bank-та болуы тиіс соңғы күні» жазылсын. Транш deadline осы ертерек күннен кері есептеледі.

Мысалы, invoice дүйсенбі таңертең төленсе, жұма кешкі trade жеткілікті деп болжауға болмайды. Platform withdrawal SLA, банк жұмыс уақыты және қосымша account review ықтималдығы ескеріліп, ішкі buffer қосылады. Buffer әмбебап сағат саны емес; соңғы үш айдағы нақты settlement журналынан алынады.

Жоспарланған күн мерекеге немесе maintenance терезесіне түссе, транш автоматты түрде алдыңғы қауіпсіз күнге ауысады. Оператор баға қолайлы болмағаны үшін оны соңғы сәтке қайта жылжыта алмайды. Өзгеріс тек жаңа cash-flow есебі, approver және жазылған себеппен жасалады.

Forecast нұсқасын мәміле алдында қатырыңыз

Транш басталғанда қолданылған forecast revision өзгермейтін snapshot ретінде сақталсын. Онда obligation тізімі, KZT balance, BTC bucket, reference price, fee assumptions, соңғы қауіпсіз күн және approval болады. Кейінгі нақты нәтижені осы snapshot-пен салыстыру керек; мәміледен кейін бастапқы болжамды қайта жазу variance-ті жасырады.

Жаңа invoice немесе күтпеген payout келсе, ескі ticket үнсіз өзгертілмейді. Жаңа revision жасалып, айырмасы түсіндіріледі: транш көлемі өсті ме, төмендеді ме, deadline ауысты ма және coverage қалай өзгерді. Екі нұсқа да аудит үшін сақталады.

Ай соңындағы variance төрт бөлікке бөлінеді: өндіріс ауытқуы, BTC/KZT баға ауытқуы, fee/settlement ауытқуы және жоспардан тыс міндеттеме. Сонда команда жақсы баға түскені үшін әлсіз процесс нәтижесін «сәтті» деп, ал қауіпсіз уақытында сатылған траншты кейін баға өскені үшін «қате» деп бағаламайды.

Сату мандатын алдын ала бекітіңіз

Күн сайынғы BTC сатылымын бір оператордың еркіне қалдырмаңыз. Treasury mandate кім ұсыныс жасайтынын, кім мақұлдайтынын, тәуліктік/апталық лимитті, рұқсат етілген venue-ді және қандай жағдайда сату тоқтайтынын анықтайды. Лимит fiat сомасымен ғана емес, treasury BTC-нің үлесімен де көрсетілсін.

Мандат үш мақсатты ажыратады: міндетті төлем үшін liquidity, тәуекелді азайту үшін жоспарлы конверсия және стратегиялық reserve. Бір мақсаттың BTC-сі екіншісіне үнсіз ауыспайды. Электр шоты күтпеген жерден өссе, reserve-ті пайдалану бөлек exception approval алады.

Қол қою құқығы мен exchange trading құқығы бөлінеді. Бір адам wallet-тан шығарып, exchange-та сатып, банк beneficiary-сін өзгерте алса, қате мен алаяқтық тәуекелі шоғырланады. Шағын командада толық бөлу мүмкін болмаса, address change, ірі tranche және жаңа банк шотына тәуелсіз review міндетті болсын.

Venue дайындығын баға шыққанға дейін тексеріңіз

Баға қолайлы сәтте KYC құжатының мерзімі өтіп кетсе немесе withdrawal тоқтаса, жоспар орындалмайды. Ай сайын venue readiness checklist жүргізіңіз: лицензия/қолжетімділік, account status, deposit network, payout limit, beneficiary, support арнасы және соңғы test transfer күні. Нақты fee мен төлем әдісі аккаунттағы ағымдағы беттен тексеріледі.

Бір ғана venue-ге тәуелділік concentration risk береді, бірақ бірнеше аккаунт ашудың өзі redundancy емес. Backup venue-де KYC аяқталған, wallet allowlist тексерілген және шағын test өткен болуы керек. Оның құқықтық жарамдылығын қолданар ел мен ұйым түріне сай тексеріңіз.

Venue outage кезінде оператор market order-ды басқа жерге соқыр көшірмейді. Price source, spread, liquidity және settlement route қайта бағаланып, жаңа execution ticket ашылады. Бұл «өткізіп алған бағаға» қуып, тәуекел лимитін бұзбауға көмектеседі.

Әр tranche үшін орындалу билетін сақтаңыз

Execution ticket жоспарланған BTC, minimum net KZT, рұқсат етілген spread/slippage, venue, order түрі және expiry уақытын көрсетеді. Орындалған соң actual fill, fee, txid, trade ID, fiat withdrawal және bank credit байланысады. Partial fill болса, қалған бөлік автоматты түрде келесі tranche деп саналмайды; жаңа шешім қажет.

Нәтижені экрандағы соңғы бағамен емес, net execution price-пен бағалаңыз:

Net execution price = банкке түскен таза KZT / сатылған BTC

Бұл сан trading fee, withdrawal fee және банк шығынын бірге көрсетеді. Бірақ салықтық есепті бөлек кәсіби саясат анықтайды. Басқарушылық метрика мен заңдық кіріс тануды араластырмаңыз.

Әр ticket-ке пайдаланылған price snapshot пен уақыт белдеуі қосылады. Кейін нарық қозғалғанда операторды hindsight арқылы бағаламау үшін мандатқа сәйкестік execution сәтіндегі дерекпен тексеріледі.

P2P есеп айырысуында қаражаттың түсуін бөлек растаңыз

P2P қолданылса, чаттағы «төледім» белгісі банк ақшасының қайтарымсыз түскенін дәлелдемейді. Asset release тек ұйымның өз банк интерфейсіндегі нақты credit, payer сәйкестігі және order мәліметі тексерілгеннен кейін орындалады. Скриншот, SMS немесе қарсы тарап жіберген чек жалғыз дәлел болмайды.

Үшінші тұлға төлемі, бөлінген бірнеше аударым, атауы сәйкес емес payer немесе асығыс release қысымы exception санатына түседі. Платформадағы dispute тәртібі сақталып, қызметкер жеке мессенджерге шықпайды. Құпия account немесе клиент дерегі мақалада және ішкі ticket-те қажеттен артық таратылмайды.

P2P көлемі өскенде AML, банк және салық салдарын жергілікті маман қайта бағаласын. Платформада функцияның болуы ұйым үшін барлық операция заңды және тәуекелсіз дегенді білдірмейді.

Сату жоспарын cash forecast-пен байланыстырыңыз

Төлем күнтізбесі электр, hosting, жалақы, жөндеу, салық және debt service-ті бөлек көрсетеді. Әр міндеттеме үшін due date, confidence және KZT buffer бар. BTC tranche сол міндеттеменің мерзіміне дейін settlement уақытын ескеріп жоспарланады; соңғы күні сату operational delay тәуекелін көбейтеді.

Forecast үш сценариймен жаңартылады: BTC бағасы төмендейді, network difficulty өседі немесе uptime нашарлайды. Бір уақытта екі фактор өзгеретін compound stress те қажет. Buffer тек орташа айға емес, stress кезеңіндегі міндетті төлемге жетуі тиіс.

Артық сату да тәуекел: болашақта BTC бағасы өссе, opportunity cost туындайды. Сондықтан шешімнің мақсаты «ең жоғары бағаны табу» емес, міндеттемені орындап, белгіленген reserve саясатын сақтау.

Апталық review шешімін бір кестеге жинаңыз

Review pack opening BTC, mined BTC, pending pool reward, planned sales, actual sales, ending BTC, KZT liquidity және ашық exception-дарды байланыстырады. Әр variance себебі production, price, execution, fee немесе timing санатына түседі. «Нарық өзгерді» деген жалпы түсініктеме жеткіліксіз.

Stop trigger ретінде account restriction, белгісіз beneficiary, reconciliation айырмасы, spread лимитінің бұзылуы, төлемнің қайтарылу қаупі немесе ресми venue мәртебесінің өзгеруі жазылады. Trigger іске қосылса, жоспардан қалу себебі құжатталып, қауіп жойылғанша келесі tranche орындалмайды.