Қазақстанда майнинг hosting шартын қалай тексеру керек

Hosting шарты ASIC-ті розеткаға қосу қызметінен әлдеқайда кең. Ол кімнің майнинг лицензиясы мен электр қатынасы қолданылатынын, kWh қалай өлшенетінін, downtime кімге тиесілі екенін, құрылғыны кім ұстайтынын және келісім тоқтағанда машинаны қалай қайтарып алатыныңызды анықтауы керек.

Дерек 2026-08-09 күні тексерілді. Қазақстанның цифрлық активтер туралы заңы мен лицензиялау қағидалары жаңаруы мүмкін; мәміле алдында ресми Adilet/gov.kz нұсқасын және жергілікті заңгер пікірін тексеріңіз.

Мазмұны

Алдымен тарап пен лицензия моделін анықтаңыз
Электр бағасының толық формуласы
SLA нақты өндірісті өлшесін
Құрылғыны қабылдау және сақтау
Шығын мен жөндеу
Дерек және қауіпсіздік
Шығу жоспары
Қол қою алдындағы no-go
Контрагентті шарттан бөлек тексеріңіз
Шоттағы әр жолдың формуласы шартта болсын
Жиі қойылатын сұрақтар

Алдымен тарап пен лицензия моделін анықтаңыз

Қазақстанның цифрлық активтер туралы заңында digital mining license subtype I және II модельдері ажыратылады. Шартта hosting провайдер, miner, power counterparty және жабдық иесі нақты заңды атаумен жазылсын. «Барлық рұқсат бар» деген жалпы кепілдік жеткіліксіз: лицензия нөмірі, subtype, мерзім, қызмет ауқымы және өзгеріс туралы хабарлау міндеті керек.

Электр кімнің атына алынатыны, meter point, grid/market шарты және заңды төлем/есеп кімге тиесілі екені көрсетіледі. Провайдердің рұқсаты клиенттің барлық міндетін автоматты жоймайды.

Электр бағасының толық формуласы

KZT/kWh санына не кіретінін бөліңіз: энергия, transmission/distribution, capacity/demand, майнингке қолданылатын төлем, салық, cooling және provider markup. айлық шот = тексерілген meter kWh × шарттық компоненттер + бекітілген fixed fee.

Meter ID, calibration, оқу аралығы, фото/CSV қолжетімділігі және дау болғандағы тексеру жазылсын. Бір жалпы есептегіштен бөлу болса, allocation әдісі және auxiliary электрді кім төлейтіні анық болуы тиіс.

SLA нақты өндірісті өлшесін

Availability тек электр бар сағат емес. Pool-да accepted hashrate жоғалған уақыт, жоспарлы maintenance, сыртқы grid outage, клиент firmware ақауы және provider cooling ақауы бөлек категория болады. Service credit формуласы, cap және claim мерзімі көрсетіледі.

Жауап беру уақыты мен қалпына келтіру уақытын араластырмаңыз. Remote reset, onsite diagnosis, spare replacement және client approval үшін жеке шек қойыңыз. Жоспарлы тоқтауды қанша күн бұрын хабарлау керектігі жазылсын.

Құрылғыны қабылдау және сақтау

Serial inventory, фото, күй, firmware hash/version және sealed accessory тізімі екі тарап қол қойған актіде болады. Қойма/залға кім кіре алады, CCTV retention, өрт/су/ұрлық сақтандыруы, insurer exclusion және deductible тексеріледі.

Провайдер құрылғыны басқа нысанға жылжыта ала ма, hashboard немесе PSU-ды ауыстыруға кім рұқсат береді, donor part қолдануға бола ма — шартта алдын ала шешіледі. Pool address өзгерісі екі факторлы рұқсатпен орындалсын.

Шығын мен жөндеу

Preventive maintenance пакетке кіре ме? Filter, cleaning, fan, labor, shipping және warranty claim кім төлейді? Баға кестесінде parts markup және алдын ала approval шегі болсын. «Нарық бағасы бойынша» деген ашық жол бюджетке бақылау бермейді.

Downtime кезінде электр есептеле ме, fixed rack fee сақтала ма, SLA credit сол шотқа қолданыла ма — үш сұрақтың жауабы бөлек жазылуы керек.

Дерек және қауіпсіздік

Клиент read-only hashrate, power, temperature, incident және billing export ала алуы тиіс. API credential мен wallet private key provider-ге берілмейді. Remote access named account, MFA, log және revoke тәртібімен шектеледі.

Firmware өзгерісі бүкіл паркке бірден емес, pilot және rollback арқылы. Malware оқиғасы, wallet address ауысуы және дерек бұзылуы бойынша notification мерзімі мен evidence preservation көрсетіледі.

Шығу жоспары

Termination notice, outstanding invoice, құрылғыны өшіру, орау, serial reconciliation, pickup deadline, storage fee және тасымалдаушы жауапкершілігі жазылсын. Провайдер төлем дауына байланысты жабдықты ұстап қала ала ма деген lien тармағын заңгер тексеруі керек.

Шығу сынағы ретінде жылына бір рет бір машинаны алып қайту процесін tabletop немесе нақты шағын тестпен тексеріңіз. Exit тек шарттың соңында ойланатын мәселе емес.

Қол қою алдындағы no-go

Лицензия/тарап анық емес; meter дерегі берілмейді; шексіз баға өзгерту құқығы; SLA тек «best effort»; serial актісі жоқ; provider wallet key сұрайды; құрылғыны қайтару мерзімі белгісіз — бұлардың кез келгені түзетілмей қол қоюға болмайтын белгі.

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

Ең арзан kWh ұсынысы жақсы ма?

Тек барлық компонент, downtime, cooling және шығу шығыны салыстырылғанда ғана бағалауға болады.

Лицензияның көшірмесі жеткілікті ме?

Жоқ. Ағымдағы ресми жазба, subtype, мерзім және қызмет ауқымы тексеріледі.

SLA credit жоғалған BTC-ді толық өтеуі керек пе?

Бұл коммерциялық келіссөз мәселесі; формула, cap және exclusion нақты жазылуы тиіс.

Контрагентті шарттан бөлек тексеріңіз

Шарттағы атауды ресми тіркеу, БСН/ИИН, заңды мекенжай, директор/қол қоюшы өкілеттігі және банк реквизитімен салыстырыңыз. Brand немесе Telegram атауы заңды тарап емес. Лицензияны суреттен емес, мемлекеттік рұқсат тексеру сервисінен нөмірі, subtype, берілген күні, арнайы шарты және ағымдағы мәртебесі бойынша тексеріңіз.

2026 жылғы қолданыстағы лицензиялау қағидалары өзгерістер тарихымен бірге Adilet-те беріледі. Шартқа «заң өзгерсе хабарлау» ғана емес, қай тарап жаңа талапты орындайды, дәлелді қашан береді және орындалмаса қандай exit құқығы бар екені жазылсын. Жергілікті заңгер нақты мәмілені тексеруі керек.

Провайдердің электр контрагентін, нысанға заңды құқығын және сақтандыруын да қараңыз. Лицензия болуы ғимаратты пайдалану, grid relation, өрт қауіпсіздігі немесе сіздің жабдыққа қатысты барлық құқықты автоматты дәлелдемейді.

Site annex әр нысанды жеке сипаттасын

Бір master agreement бірнеше алаңға қолданылса, әр нысанға site annex қажет: толық мекенжай, лицензия қосымшасындағы location, зал/rack, meter ID, келісілген kW, cooling түрі, желі, күзет, insurance policy және emergency contact. Провайдер жазбаша рұқсатсыз жабдықты басқа нысанға көшіре алмауы керек.

Annex-ке single-line diagram немесе инженерлік reference, rack layout, fault domain және қабылдау photos қосылады. Қауіпті техникалық сызба жарияланбайды; клиент пен білікті маманның бақыланатын архивінде сақталады. Сызба нақты жағдайға сәйкес болмаса, қосымша ASIC кіргізу тоқтайды.

Нысан capacity-і «up to» деп жазылмай, committed және reserved kW ретінде көрсетіледі. Артық сатылған қуат, басқа клиенттің өсуі немесе utility curtailment кезінде allocation тәртібі мен басымдық алдын ала анықталсын.

Onboarding алдындағы condition precedent

Төлем немесе ASIC жеткізу басталғанға дейін орындалатын шарттарды тізіңіз: белсенді лицензия дәлелі, site annex, электр capacity sign-off, insurance certificate, meter baseline, serial inventory формасы, data access, bank details verification және exit pickup procedure. Біреуі орындалмаса, client delivery-ді кейінге қалдыра алады.

Deposit қайтарылатын жағдай және provider deadline-ы нақты болсын. «Site ready soon» деген уәде machine shipment-ке рұқсат емес. Инфрақұрылым readiness photos, engineer sign-off және аз сынақ құрылғысымен commissioning арқылы дәлелденеді.

Қабылдау кезеңі басталғанда екі тараптың өкілі, өлшеу құралы, тест ұзақтығы және pass/fail шегі жазылған протокол қолданылады. Провайдердің өз dashboard-ы жалғыз дәлел болмайды; client read-only pool және meter дерегін салыстырады.

Электр шотының audit trail-ы

Invoice әр component-ті бөлек көрсетсін: бастапқы meter, соңғы meter, multiplier, kWh, unit price, fixed fee, cooling/auxiliary allocation, mining payment, салық және credit. Қолданылатын formula шарт қосымшасында version-controlled болуы керек. PDF шоттың артында CSV немесе machine-readable detail беріледі.

Meter replacement, calibration failure немесе дерек жоғалса estimation әдісі алдын ала жазылады. «Провайдер есебі түпкілікті» деген біржақты тармақ қабылданбайды. Client meter photo, export және тәуелсіз тексеру сұрай алады; айырма tolerance-тан асса invoice dispute ашылады.

Dispute кезінде даусыз сома төленіп, даулы бөлік уақытша hold болуы мүмкін — нақты тәртіпті заңгер келіседі. Провайдер даулы аз сома үшін барлық ASIC-ті дереу өшіруге құқылы ма, cure period бар ма және emergency safety жағдайы қалай ерекшеленеді деген сұрақтар жазбаша шешіледі.

SLA-ны fault category және evidence-пен байланыстыру

SLA кестесінде оқиға басталған/аяқталған уақыт, affected serial/rack, cause owner, accepted-hashrate impact және evidence source болады. Grid outage, provider distribution, cooling, network, planned maintenance, client firmware және force majeure бөлек кодталады. Бір оқиғаға бірнеше себеп болса, attribution тәртібі алдын ала бекітіледі.

Provider dashboard, client monitoring және pool дерегі айырылса, қай timestamp және timezone қолданылатыны жазылсын. Service credit автоматты есептеле ме, claim қажет пе, claim мерзімі мен cap қандай — бәрі formula түрінде беріледі.

Force majeure тым кең болмауы керек. Жай spare жетіспеуі, персонал болмауы немесе жоспарланбаған maintenance автоматты түрде форс-мажорға айналмайды. Заңгер жергілікті құқыққа сай анықтаманы, notification және mitigation міндетін қарайды.

Құрылғы custody және бөлшек ізін сақтау

Serial-level актіге machine, PSU, control board және маңызды аксессуар күйі кіреді. Repair кезінде removed part, replacement part, technician, reason және warranty case жазылады. Бір клиенттің бөлшегін екіншісіне donor ретінде қолдану тек алдын ала жазбаша рұқсатпен жасалады.

Залға named access, visitor log және CCTV retention керек. Camera coverage бар деген мәлімдеме footage алу құқығын білдірмейді; incident кезінде кім сұрайды, қанша күн сақталады және privacy талабы қалай орындалады деген процесс болуы тиіс.

Құрылғы жоғалса, су/өрт зақымдалса немесе үшінші тұлға талап қойса notification, evidence preservation, insurer claim және liability cap жұмыс істейді. Insurance certificate-пен бірге insured party, asset scope, exclusions, deductible және payout beneficiary тексеріледі.

Жөндеу authority matrix

Remote reboot, firmware rollback, fan replacement, PSU ауыстыру, hashboard repair және manufacturer warranty shipment үшін әртүрлі approval деңгейі қажет болуы мүмкін. Authority matrix кім қандай KZT шегіне дейін мақұлдайтынын және emergency әрекетті көрсетеді.

Provider parts markup, labor rate, diagnostic fee, shipping және storage-ті алдын ала price schedule-да көрсетеді. Ашық «market price» жолына кемінде quotation evidence және client approval керек. Repair басталғанға дейін estimated return-to-service және downtime billing статусы беріледі.

Қайталанатын ақау root-cause review-ға өтеді. Бір ASIC-ті бірнеше рет жөндеу орнына replacement немесе exit экономикалық тиімді болуы мүмкін. Provider service credit пен repair invoice-ті бір-бірінен бөлек есептейді.

Дерекке қолжетімділік және киберқауіпсіздік

Client-ке read-only machine status, pool hashrate, power, temperature, alarm, ticket және invoice export беріледі. Дерек retention мерзімі, export форматы және API өзгерісі туралы notice жазылсын. Шарт аяқталғанда client өз тарихын machine-readable форматта ала алуы керек.

Provider wallet seed/private key немесе exchange credential сұрамауы тиіс. Pool configuration үшін payout address change dual approval, allowlist және audit log арқылы жасалады. Remote account named, MFA-мен қорғалған және қызметкер кеткенде revoke болады.

Security incident кезінде affected system, белгілі timeline, жасалған containment және client action туралы notification мерзімі болады. Provider evidence-ті сақтап, root-cause report береді. Penetration test немесе audit құқығы safety және басқа клиент құпиясымен теңгеріледі.

Change control: баға, алаң және заң

Unit price өзгерісіне notice period, объективті index немесе documented cost component, client objection және termination option беріледі. Провайдер біржақты кез келген күні кез келген баға қоюға тиіс емес. Заңдық mining payment өзгерсе, invoice-де ресми негіз және күшіне енген күн көрсетіледі.

Site move, meter change, cooling redesign, subcontractor, insurer немесе лицензия мәртебесі material change болып саналады. Client consent қажет пе, қайта commissioning қалай өтеді және жаңа тәуекелді кім төлейді — change request-те шешіледі.

Subcontractor қолданылса да негізгі provider жауапкершіліктен толық босамауы керек. Оның access, security, insurance және data міндеті негізгі шарттан төмен болмауы тиіс.

Exit rehearsal және жабдықты қайтару

Exit күнінде serial reconciliation, shutdown log, pool address freeze, config/data export, photos, packing, pickup appointment және transport handover жасалады. Құрылғының шарттағы күйден қалыпты wear салдарынан айырмасы мен provider damage бөлек бағаланады.

Outstanding invoice бар болса lien немесе retention құқығын жергілікті заңгер нақты тексереді. Даулы сома мен мойындалған қарызды ажырату, cure period, storage fee cap және client inspection құқығы жазылсын. Жабдықты белгісіз мерзімге ұстап қалу — no-go.

Жыл сайын бір машинаны шығарып көру address, access, paperwork және carrier процесінің жұмыс істейтінін көрсетеді. Толық exit мүмкін болмаса tabletop exercise, бірақ жауапты адам мен қажетті құжат нақты тексеріледі.

Шартты ай сайын басқару

Contract register-де лицензия/insurance expiry, invoice due, SLA incident, open repair, data export, price notice және exit obligation көрсетіледі. Ай сайын provider мен client exception тізімін жабады. Қол қойылған шарттың папкада жатуы бақылау емес.

Тоқтату/эскалация шарттары: лицензия мәртебесі расталмайды; meter export берілмейді; invoice formula өзгерген; insurance lapse; provider payout address өзгертуді сұрайды; serial айырмасы бар; repeated safety alarm жабылмаған; немесе exit pickup-қа кедергі жасалады.

Renewal автоматты болмауы тиіс. Мерзім аяқталмай тұрып нақты uptime, net KZT/kWh, repair turnaround, invoice disputes, security incidents және exit readiness бағаланады. Ең арзан жаңа quote емес, толық тәуекел мен дәлел шешім береді.

Кепілдік мәлімдеме мен өзгеріс журналын ұстаңыз

Provider шартқа қол қойған күні берген маңызды мәлімдемелерді жеке register-ге шығарыңыз: лицензия белсенді; site-ке заңды құқығы бар; electricity relation жарамды; insurance күшінде; жабдыққа үшінші тұлға талабы жоқ; қол қойған адам өкілетті. Әр мәлімдемеге дәлел, тексеру күні және келесі қайта тексеру күні беріледі.

Мәлімдеме кейін дұрыс емес болып шықса, қандай remedy қолданылатыны шартта жазылсын: cure, service suspension, price adjustment, indemnity немесе termination. Бұл тармақтардың орындалуын жергілікті заңгер бағалайды; жалпы «provider бәріне жауапты» сөзі нақты қорғау бермейді.

Change notice register-де кім хабарлады, қай күні, не өзгерді, қандай құжат берілді, client analysis, deadline және шешім сақталады. Лицензия, банк деректемесі, insurer, meter, subcontractor немесе site өзгерісі мессенджердегі жай хабар ретінде жабылмайды.

Маңызды хабарлама contract notice clause-тағы ресми арнаға жіберіледі. Email spoofing немесе төлем реквизитін ауыстыру тәуекелі үшін бұрынғы тексерілген контакт арқылы out-of-band confirmation қолданылады. Расталмаған жаңа банк шотына төлем жасалмайды.

Шоттағы әр жолдың формуласы шартта болсын

Hosting invoice «электр», «қызмет» және «қосымша шығын» деген үш жалпы жолдан ғана тұрса, оны қайта есептеу қиын. Қосымшада meter serial, бастапқы/соңғы көрсеткіш, multiplier, timezone, қолданылған тариф, digital mining fee, fixed capacity және cooling allocation формуласы көрсетілсін. Формула өзгерсе, ол келесі есептік кезеңге дейін жазбаша change notice арқылы хабарланады.

Shared cooling немесе security шығыны бірнеше клиентке бөлінсе, allocation driver нақты болсын: contracted kW, measured kWh, rack саны немесе басқа негіз. Оператор бір айда driver-ды ауыстырып, бұрынғы кезеңді үнсіз қайта есептемеуі керек. Minimum charge, take-or-pay және idle rack төлемі де бөлек жолмен көрінсін.

Ай сайын клиент өз meter export-ын, pool uptime-ты және invoice-ты үш жақты салыстырады. Айырма tolerance-тен асса, disputed бөлік пен undisputed бөлік ажыратылады. Шарт төлем дауы жүріп жатқанда оператордың барлық ASIC-ті бірден тоқтата алатынын емес, қандай notice және cure period қолданылатынын көрсетуі керек.

Дау процесін төлем күніне дейін сынаңыз

Келісімге қол қойғанда billing dispute сценариін tabletop ретінде өткізіңіз. Мысалы, meter-де 1000 kWh артық көрінді делік: клиент қай файлды сұрайды, оператор қанша күнде береді, кім calibration record-ты тексереді және credit note қалай шығады? Жауап тек «account manager шешеді» болса, процесс толық емес.

Dispute ticket invoice ID, disputed amount, evidence list, owner және шешім мерзімін қамтиды. Email тізбегін ғана дәлел деп қалдырмаңыз. Нәтиже accepted, corrected немесе rejected болып жіктеліп, себебі жазылады. Бірдей қате қайталанса, әр айда ұсақ credit алу жеткіліксіз; meter, integration немесе allocation control-ы түбірімен түзетіледі.

Үлкен дауда тәуелсіз meter test немесе инженерлік review қажет болуы мүмкін. Кім төлейтіні және қате қай шектен асқанда шығынның кімге өтетіні шартта алдын ала жазылсын.

Үздіксіздік жоспарын нақты ресурспен тексеріңіз

Оператор «генератор бар» деуі мүмкін, бірақ оның қай жүктемені, қанша уақыт және қандай fuel келісімімен ұстайтыны бөлек мәселе. Business continuity annex grid outage, cooling loss, network loss, fire zone closure және staff shortage сценарийлерін қамтысын. Әр сценарийде safe shutdown, клиентке notice, recovery priority және дерек беру тәртібі болады.

Генератордың атаулы қуатын барлық ASIC-ке автоматты түрде бөлмеңіз. Cooling, pump, control және қауіпсіздік жүктемесі бірінші есептеледі. Жүктеме банкімен тест, отынның нақты қолжетімділігі және іске қосу уақыты білікті мамандармен расталсын. Тест нәтижесі клиентке келісілген summary түрінде беріледі.

Network redundancy де қағаздағы екі провайдермен бітпейді. Екі линия бір duct, бір router немесе бір upstream-ға тәуелді болса, common-cause failure қалады. Failover тесті кезінде worker reconnect, rejected share және monitoring visibility өлшенсін.

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

Exit plan asset-ті кім өшіреді, credential-ды кім жояды, қаптама мен тасымалды кім береді және outstanding invoice қалай жабылатынын көрсетеді. Оператордың lien немесе equipment hold құқығы болса, оның шегі мен dispute кезіндегі тәртібін заңгер тексереді. Клиент asset serial тізімін ай сайын жаңартып отырмаса, шығу кезінде меншік дауы туындауы мүмкін.

Offboarding алдында wallet/pool credential ауыстырылады, monitoring access жабылады және соңғы meter reading екі жақпен бекітіледі. Құрылғының фото күйі, қаптама, seal және carrier handover chain of custody-ға кіреді. Дерек сақтау мерзімі аяқталғанда оператор клиент конфигурациясы мен журналын жойғанын растайды.

Шығу rehearsal нақты көшіруді қажет етпейді. Жылына бір рет тараптар құжатты үстел үстінде өткізіп, жоғалған serial, жарамсыз байланыс немесе тасымал bottleneck-ін таба алады. SLA жақсы жұмыс істеп тұрғанда exit-ті тексеру — дағдарыс кезіндегі асығыстықтан арзан.

Өзгеріс пен ерекше жағдайды бір реестрде ұстаңыз

Тариф, firmware саясаты, rack орны, cooling режимі немесе security access өзгерсе, оның күшіне ену күні мен клиентке әсері жазылады. Оператордың «операциялық қажеттілік» деген жалпы құқығы қауіпсіздікке керек болуы мүмкін, бірақ баға мен performance міндеттемесін шексіз өзгертуге айналмауы тиіс.

Уақытша exception — мысалы, резерв fan істемей тұрғанда шектеулі жүктемемен жұмыс — иесі, өтем бақылауы және аяқталу күні бар жазба алады. Мерзімі өткен exception автоматты ұзартылмайды. Клиентке әсер ететін жоғары тәуекелді exception agreed notice тәртібімен беріледі.

Айлық governance pack change, exception, SLA breach, invoice dispute және ашық action-ды бір жерге жинайды. Бұл contract management-ті төлем тексерісінен нақты операциялық бақылауға айналдырады.