COLDCARD, Trezor और SafePal के बाद: डेटा न्यूनतमकरण के पक्ष में CLAVI

शोध की अंतिम तिथि: 19 अगस्त 2026। प्रदाताओं द्वारा बताए गए कुल को उसी रूप में चिह्नित किया गया है। यह लेख शैक्षिक है और कानूनी या incident-response सलाह नहीं है।

सीधा उत्तर: कम retained data का अर्थ है संचालक-पक्ष का कम जोखिम

डेटा न्यूनतमकरण एक सुरक्षा नियंत्रण है, क्योंकि संचालक वह रिकॉर्ड नहीं खो सकता जिसे उसने कभी एकत्र ही नहीं किया। अगला सर्वोत्तम विकल्प है केवल उतना डेटा लेना जितना किसी निर्धारित उद्देश्य के लिए आवश्यक हो, उसे अन्य प्रणालियों से अलग रखना और सत्यापित समय-सारणी के अनुसार मिटाना। लेकिन किसी संचालित कंपनी के लिए “zero data” विश्वसनीय वादा नहीं है। Shipping, invoices, support, fraud prevention और regulated services सीमित recordkeeping आवश्यकताएँ पैदा कर सकते हैं। बचाव योग्य लक्ष्य है वॉल्ट रहस्यों तक संचालक की zero access और बाकी हर जगह केवल न्यूनतम आवश्यक retention।

यह अंतर इसलिए महत्वपूर्ण है क्योंकि अगस्त 2026 के समाचार चक्र में तीन सुरक्षा घटनाओं को अक्सर “hardware-wallet hacks” के एक ही चिंताजनक शीर्षक में मिला दिया गया। वे एक समस्या नहीं थीं।

• COLDCARD घटना वॉलेट रहस्यों के निर्माण से संबंधित थी।
• Trezor घटना shipping provider में अनधिकृत पहुँच से संबंधित थी।
• SafePal disclosure order-tracking component की authorization flaw से संबंधित था।

जुलाई और अगस्त 2026 में क्या हुआ?

घटना	सार्वजनिक खुलासा या अपडेट	सुरक्षा स्तर	प्रकाशन के लिए सुरक्षित विवरण	विश्वास स्तर
COLDCARD predictable-RNG घटना	सलाह 30 जुलाई को प्रकाशित; मार्गदर्शन 14 अगस्त 2026 को अपडेट	रहस्य निर्माण	Coinkite और Block ने स्वतंत्र रूप से समस्या का कारण firmware integration की वह त्रुटि बताया जिसने deterministic fallback generator को seed-generation randomness देने की अनुमति दी।	मूल कारण पुष्ट; versions और impact के कुछ विवरण विवादित या अनुमानित हैं।
Trezor/ShipMonk exposure	सूचना 13 अगस्त 2026 को प्रकाशित	ऑर्डर-पूर्ति और पहचान डेटा	Trezor का कहना है कि ShipMonk ने लगभग 13,689 customer records को प्रभावित करने वाली unauthorized access की सूचना दी। Trezor के अनुसार उसके devices, keys और backups प्रभावित नहीं हुए।	Vendor-reported scope; स्वतंत्र reporting ने disclosure की पुष्टि की, लेकिन dataset का स्वतंत्र audit नहीं हुआ।
SafePal order-tracking exposure	खुलासा 16 अगस्त 2026 को प्रकाशित	ऑर्डर-पूर्ति और खरीद डेटा	SafePal का कहना है कि authorization flaw ने लगभग 39,798 ग्राहकों की order information उजागर की। उसके अनुसार wallet credentials और payment-card data शामिल नहीं थे।	Vendor-reported और स्थिति अभी विकसित हो रही है।

COLDCARD: air-gap कमजोर entropy की भरपाई नहीं कर सकता

COLDCARD vulnerability रहस्य बनाने की विफलता थी, customer database breach नहीं। Coinkite के तकनीकी विवरण और Block के स्वतंत्र code analysis, दोनों ने पाया कि build या linking error ने hardware-generated randomness के लिए निर्धारित स्थान पर deterministic MicroPython fallback generator का उपयोग होने दिया।

Wallet seed को अप्रत्याशित होना चाहिए। यदि संभावित seeds का दायरा इतना छोटा हो जाए कि उसे खोजा जा सके, तो attacker device से बाहर candidate keys पुनर्निर्मित कर सकता है। Wallet बंद हो सकता है, तिजोरी में रखा हो सकता है और कभी internet से न जुड़ा हो; ये सुरक्षा उपाय उस randomness को वापस नहीं लाते जो रहस्य बनाते समय अनुपस्थित थी।

यह “air-gap” के सरल वर्णनों में एक महत्वपूर्ण सुधार है। Physical और network isolation remote attack paths को काफी घटा सकते हैं, लेकिन वे यह प्रमाणित नहीं करते कि isolated boundary के भीतर हर component सही व्यवहार करता है। Entropy generation, firmware integration, reproducible builds, update procedures और independent review सुरक्षा मॉडल का हिस्सा बने रहते हैं।

Mk2/Mk3 की सटीक version boundary स्वयं evidence handling की उपयोगी सीख है। Block का analysis प्रभावित path को version 4.0.0 तक ले जाता है। Coinkite की वर्तमान advisory version 4.0.1 से शुरू होती है। चुपचाप किसी एक को चुनने के बजाय users और publishers को इस अंतर को स्वीकार करना चाहिए और किसी भी boundary के तहत बनाई गई seed के साथ सावधानी बरतनी चाहिए।

Coinkite यह भी कहता है कि corrected firmware install करने से affected firmware पर पहले बनाई गई seed मजबूत नहीं होती। Update भविष्य की seed generation को सुरक्षित करता है; affected seed को vendor की dice और passphrase caveats के अधीन, नई बनाई गई wallet में सावधानीपूर्वक migrate करना अभी भी आवश्यक है। यह अंतर हर remediation summary में होना चाहिए।

Galaxy Research के 3 अगस्त के on-chain analysis ने 1,596 BTC को तीन high-confidence waves और 14 छोटे incidents से attributed किया। इस संख्या का उपयोग केवल attribution के साथ करें। यह Coinkite द्वारा सत्यापित loss total नहीं है, और यह लेख चौथी wave या dollar estimates के उन बड़े आंकड़ों को नहीं दोहराता जो अपुष्ट रहे।

सार्वजनिक रिकॉर्ड attacker की पहचान नहीं करता और यह नहीं दिखाता कि artificial intelligence ने flaw खोजा था। एक अलग phishing campaign ने COLDCARD से जुड़ी चिंता का लाभ उठाया, लेकिन किसी reviewed source ने यह स्थापित नहीं किया कि उसने Coinkite की leaked customer list इस्तेमाल की।

Trezor: न्यूनतमकरण ने जोखिम घटाया प्रतीत होता है, समाप्त नहीं किया

Trezor का 13 अगस्त का notice ShipMonk के पास मौजूद fulfillment data से संबंधित था, compromised wallet hardware से नहीं। Trezor का कहना है कि ShipMonk ने उसे 10 अगस्त को सूचित किया। वह notification date थी, intrusion date जरूरी नहीं।

Trezor के notice ने exploit का नाम नहीं दिया। BleepingComputer ने बाद में बताया कि उसके द्वारा देखे गए ShipMonk notification emails ने access को Metabase vulnerability से जोड़ा। Metabase की primary advisory CVE-2026-72898 को एक critical, actively exploited unauthenticated SQL-injection flaw बताती है। Research cutoff तक कोई public ShipMonk postmortem या independent forensic report नहीं मिला।

Trezor ने दो प्रभावित समूह बताए:

• 11,742 ग्राहक जिनके नाम, email addresses, phone numbers और shipping addresses उजागर हुए।
• 1,947 ग्राहक जिनके नाम, शहर और email addresses पूर्ण shipping addresses के बिना उजागर हुए।

इससे लगभग 13,689 का reported total बनता है, “exactly 14,000” नहीं। Trezor का कहना है कि अधिकांश प्रभावित records उन ग्राहकों से जुड़े थे जिन्हें 10 मई से 8 अगस्त 2026 के बीच United States, United Kingdom, Sweden, Colombia, Brazil, Italy या Portugal में orders मिले। उसने अलग से सावधान किया कि partial records में पुराने orders शामिल हो सकते हैं और वह ShipMonk के साथ exact period की जाँच कर रहा था।

Trezor के अनुसार उसके अपने systems, hardware wallets, private keys और wallet backups प्रभावित नहीं हुए। Trezor यह भी कहता है कि parcel contents उजागर नहीं हुए। ये महत्वपूर्ण सीमाएँ हैं, लेकिन वे नामों और घर के पतों को निरापद नहीं बनातीं। Identity और delivery information fraudulent support message को अधिक विश्वसनीय बना सकती है और targeting risk बढ़ा सकती है। Notice यह स्थापित नहीं करता कि physical attack हुआ, इसलिए risk को confirmed consequence के रूप में नहीं लिखा जाना चाहिए।

Trezor की प्रकाशित retention table कहती है कि completed या cancelled e-shop orders और delivery का मुख्य data आम तौर पर 90 दिनों बाद delete किया जाता है, ongoing-order exceptions के अधीन। लगता है इस policy ने उपलब्ध पूर्ण shipping addresses की संख्या सीमित की। उसने incident को समाप्त नहीं किया, और older-partial-record caveat किसी को policy को पूर्णतः लागू बताने से रोकता है।

वही table यह भी दिखाती है कि “Trezor 90 दिनों बाद customer data delete करता है” कहना गलत है। अलग उद्देश्यों के लिए अलग periods हैं: separate environment में invoice data दस वर्ष, third-party fiat payment data अधिकतम सात वर्ष, कुछ crypto-payment records संबंध समाप्त होने के बाद पाँच वर्ष और closed support tickets 120 दिनों बाद anonymized। Marketing और referral data के नियम भी अलग हैं।

वास्तविक न्यूनतमकरण ऐसा दिखता है: एक slogan या timer नहीं, बल्कि data-category map। महत्वपूर्ण प्रश्न यह है कि map merchant, warehouse, carrier, support platform, payment processor, replicas और backups में लागू है या नहीं।

SafePal: वॉलेट सुरक्षित रह सकता है जबकि उसके खरीदार दिखाई देने लगें

SafePal का खुलासा वाणिज्यिक डेटा की एक और विफलता का वर्णन करता है, न कि वॉलेट के गोपनीय डेटा से समझौते की रिपोर्ट। SafePal का कहना है कि ऑर्डर-ट्रैकिंग प्लग-इन में अनुमति-संबंधी खामी से 2 मार्च 2025 से 11 अप्रैल 2026 के बीच ऑर्डर देने वाले लगभग 39,798 ग्राहकों की जानकारी उजागर हुई।

SafePal के अनुसार exposed fields में names, email addresses, shipping addresses, phone numbers और purchase details शामिल थे। Company का कहना है कि incident में seed phrases, private keys, wallet passwords, अन्य wallet credentials, bank-account information, payment-card numbers या government identification numbers शामिल नहीं थे।

ये statements vendor-reported हैं। सुरक्षित निष्कर्ष इससे संकरा है: किसी नामित व्यक्ति ने security product खरीदा, यह जानकारी तब भी मूल्यवान हो सकती है जब product secrets सुरक्षित रहें।

Hardware provider के लिए checkout और tracking stack security perimeter के बाहर बैठा “ordinary e-commerce” नहीं है। यह real identity, delivery location, contact channels और security-sensitive purchase को जोड़ सकता है। इस combination को संभालने वाला हर plug-in और fulfillment partner ग्राहक के threat model का हिस्सा बन जाता है।

Zero data का अर्थ एक ही चीज नहीं है

“कोई डेटा एकत्र न करें” उपयोगी design challenge है, लेकिन अधूरी operating policy है। Personal Vault और उसे बनाने या support करने वाली company अलग-अलग information categories संभालते हैं।

सबसे कठोर लक्ष्य vault-secret plane पर लागू होता है: provider को private keys, recovery material, CLAVI के स्वामित्वाधीन AI के local prompts या अन्य protected contents पहली जगह पर प्राप्त ही नहीं होने चाहिए। CLAVI की public documentation इसे अपने Personal Vault का design objective बताती है। यह user secrets तक operator access के बारे में product-architecture claim है, यह दावा नहीं कि CLAVI Switzerland AG के पास कोई business records नहीं हैं।

Commerce और corporate records के लिए अलग discipline चाहिए:

डेटा वर्ग	बचाव योग्य उद्देश्य	“कुछ भी न रखें” अधूरा क्यों हो सकता है
Vault secrets और protected local content	Architecture द्वारा operator-inaccessible रखें; support के माध्यम से कभी न मांगें।	इन records को न जुटाना operator-side exposure को सबसे सीधे हटाता है।
Order और delivery data	चुने गए carrier द्वारा आवश्यक न्यूनतम fields जुटाएँ; उन्हें अलग रखें; delivery, returns और dispute windows के बाद expire करें।	Privacy-preserving pickup option के बिना कोई physical product किसी delivery mechanism के बगैर customer तक नहीं पहुँच सकता।
Invoices और accounting evidence	Required accounting records बनाने और प्रमाणित करने के लिए केवल आवश्यक information अलग system में रखें।	Swiss accounting rules accounting records और accounting vouchers के साथ annual report और audit report को दस वर्ष रखने की मांग कर सकते हैं; यह पूरे CRM profile को रखने की अनुमति नहीं है।
Support records	Secrets पर रोक लगाएँ, attachments न्यूनतम रखें, reshipment addresses अलग करें और closed cases को expire या anonymize करें।	Active warranty, replacement या dispute के लिए सीमित record आवश्यक हो सकता है।
Marketing data	Participation optional रखें और consent records को fulfillment से अलग रखें।	Order को चुपचाप indefinite profiling permission नहीं बनना चाहिए।
Security evidence और legal holds	Incident या valid legal duty की आवश्यकता पर documented, narrowly scoped set सुरक्षित रखें; exception की review करें।	Routine deletion किसी specific investigation या preservation duty के लिए कानूनन रुक सकती है, लेकिन exception permanent default नहीं बननी चाहिए।

सिद्धांत “परिणाम की परवाह किए बिना सब कुछ मिटा दो” नहीं है। सिद्धांत है “हर retained field से उसके अस्तित्व का औचित्य मांगो।”

GDPR, Swiss law और crypto rules वास्तव में क्या मांगते हैं?

कानूनी landscape न्यूनतमकरण का समर्थन करता है, लेकिन एक universal retention schedule निर्धारित नहीं करता। Applicability company, customer, processing purpose, service और jurisdiction पर निर्भर करती है। निम्न विवरण scope map है, legal advice नहीं।

Framework	सुरक्षित रूप से क्या कहा जा सकता है	इसका क्या अर्थ नहीं है
GDPR	Article 5 personal data को adequate, relevant और necessary सीमा तक सीमित रखने तथा आवश्यकता से अधिक समय तक न रखने की मांग करता है। Article 25 design और default द्वारा data protection मांगता है।	GDPR हर company से zero data collection की मांग नहीं करता और न ही एक single local-only architecture निर्धारित करता है।
GDPR breach notification	Controller supervisory authority को undue delay के बिना और, जहाँ संभव हो, awareness के 72 घंटे के भीतर सूचित करता है, जब तक कि यह असंभाव्य न हो कि breach से natural persons के rights और freedoms के लिए risk उत्पन्न होगा। High risk की संभावना पर, exceptions के अधीन, लोगों को undue delay के बिना सूचित किया जाता है।	हर incident की घोषणा 72 घंटे में सभी लोगों को करना आवश्यक नहीं है।
Swiss FADP	Article 7 design और default द्वारा data protection की मांग करता है, जिसमें purpose के लिए आवश्यक processing तक सीमित default settings शामिल हैं। Article 24, high risk की संभावना वाले breach पर “as soon as possible” standard लागू करता है।	Swiss law GDPR की fixed 72-hour formulation इस्तेमाल नहीं करता।
Swiss accounting law	Code of Obligations का Article 958f accounting records और accounting vouchers के साथ annual report और audit report को financial year की समाप्ति से दस वर्ष तक रखने की मांग करता है।	यह unrelated telemetry, marketing profiles, support files या wallet data पर ten-year storage लागू नहीं करता।
MiCA	In-scope crypto-asset service provider specified services, activities, orders और transactions के records पाँच वर्ष, तथा timely authority request के बाद संभवतः सात वर्ष रखता है। CASP status इस पर निर्भर करता है कि provider पेशेवर रूप से clients को MiCA-listed एक या अधिक services देता है या नहीं। Clients के crypto-assets या access means की safekeeping या control खास तौर पर custody test के लिए relevant है; transfer, execution, exchange, advice और अन्य listed services के अलग tests हैं।	हर hardware seller स्वतः CASP नहीं है, और MiCA हर customer field रखने की मांग नहीं करता।
EU Transfer of Funds Regulation	Information duties EU CASP को शामिल करने वाले सभी in-scope transfers पर लागू होती हैं। Client के self-hosted address से या उसकी ओर €1,000 से अधिक transfers अतिरिक्त assessment को trigger करते हैं कि वह address client के ownership या control में है या नहीं। Specified information पाँच वर्ष रखी जाती है; Member State केवल AML/CFT purposes के लिए necessity और proportionality assess करने के बाद ही अधिकतम पाँच अतिरिक्त वर्ष रखने की अनुमति या requirement दे सकता है।	€1,000 सामान्य Travel Rule threshold नहीं है। CASP के बिना pure person-to-person transfers बाहर हैं।
Swiss CARF implementation	Swiss SIF कहता है कि framework 1 जनवरी 2027 से पहले लागू नहीं हो सकता और उसका legal basis 2026 में लागू नहीं होता। OECD CARF in-scope service providers के लिए reportable-user identity और aggregated relevant transactions को cover करता है।	Switzerland ने CARF को 1 जनवरी 2026 को लागू नहीं किया, और CARF हर hardware-wallet buyer की holdings का universal database नहीं है।

MiCA, Travel Rule, DORA, Swiss AMLA और CARF को “hardware”, “self-custody” या “non-custodial” जैसे labels के आधार पर CLAVI पर लागू या उससे बाहर नहीं माना जा सकता। Analysis key access, signing या intervention capability, transfer और exchange services, smart-contract controls, contractual roles और continuing customer relationships से बदल सकता है। Public exclusion बताने से पहले production feature set की qualified legal review आवश्यक है।

European Data Protection Board की final Guidelines 02/2025 v2.0, 7 जुलाई 2026 को अपनाई गई, एक और boundary जोड़ती हैं। Wallet addresses और public keys personal data हो सकते हैं जब उन्हें यथोचित रूप से natural person से जोड़ा जा सके। Encryption personal data को anonymous बनाए बिना उसकी रक्षा कर सकता है। Guidance सामान्यतः personal data on-chain रखने के विरुद्ध सलाह देती है क्योंकि immutable storage deletion को जटिल बनाता है, लेकिन यह ऐसे सभी processing पर categorical legal ban नहीं है।

CLAVI के Personal Vault के लिए data-boundary model

CLAVI को privacy का वर्णन inspectable boundary के रूप में करना चाहिए, absolute adjective के रूप में नहीं। CLAVI की canonical definition product को digital assets, private data और private communications के लिए Personal Vault के रूप में प्रस्तुत करती है। उपयोगी अगला कदम category-by-category यह बताना है कि operator किस तक पहुँच सकता है और operating company को अभी भी क्या process करना पड़ता है।

Public model को हर data class के लिए सात प्रश्नों का उत्तर देना चाहिए:

1. Purpose: यह field क्यों मौजूद है?
2. Minimum fields: कौन-से attributes सख्ती से आवश्यक हैं?
3. System: Record कहाँ stored है और क्या वह अन्य purposes से अलग है?
4. Access: कौन-से roles और processors उसे देख सकते हैं?
5. Expiry trigger: Clock collection, delivery, ticket closure, relationship termination या financial-year end में से कब शुरू होती है?
6. Deletion evidence: Production copies, replicas, processor systems और backups कैसे cover होते हैं?
7. Exception: क्या deletion रोक सकता है, कौन approve करता है और review कब होती है?

CLAVI Ledger से प्रतिस्पर्धा क्यों नहीं कर रहा के साथ पढ़ने पर मुद्दा यह नहीं है कि एक security mechanism हर attack को हरा देता है। Personal Vault कई layers जोड़ता है: secret generation, signing authority, local processing, physical control, सावधानी से सीमित corporate data और legal environment। हर layer का failure mode अलग है।

न्यूनतमकरण को operations में बदलने वाले नौ controls

Policy तभी risk घटाती है जब systems और processors उसे लागू करते हैं। Hardware और Personal Vault providers के लिए practical control set स्पष्ट है, भले implementation कठिन हो।

1. Field-level purpose register बनाए रखें। “Order data” बहुत अस्पष्ट है। Name, street address, phone, email, SKU और tracking ID में से हर एक के लिए documented purpose और owner चाहिए।
2. Data को purpose के अनुसार अलग करें। Fulfillment, accounting, support, marketing और security evidence एक searchable customer profile नहीं बनने चाहिए।
3. Optional fields को वास्तव में optional बनाएं। Carrier की local requirement universal checkout requirement नहीं बननी चाहिए।
4. Short operational lifetimes इस्तेमाल करें। Defined event से expiry शुरू करें और active returns, warranties या disputes के extensions document करें।
5. Processor deletion verify करें। Contract language को deletion jobs, reports, sampling या audit rights का समर्थन होना चाहिए, जो warehouses, carriers और sub-processors को cover करें।
6. Backups को expiry के लिए design करें। Record meaningful रूप से deleted नहीं है यदि वह long-lived backups से routinely restorable और queryable रहता है। जहाँ immediate removal impractical हो, restoration सीमित करें और returned data के active होने से पहले deletion दोबारा लागू करें।
7. Secrets को support से बाहर रखें। Staff, forms और automated tools को recovery phrases, private keys या vault contents कभी नहीं मांगने चाहिए। Sensitive attachments के लिए explicit handling और expiry rules चाहिए।
8. Parcel का अर्थ घटाएँ। Neutral packaging, generic sender details और lawful locker या pickup options association घटा सकते हैं, लेकिन किसी को guaranteed anonymity के रूप में market नहीं करना चाहिए।
9. Exceptions को सामान्य बनाए बिना उनकी योजना बनाएं। Incident evidence और legal holds के लिए recorded scope, approval, review date और release process चाहिए।

कोई control landscape को static नहीं बनाता। Attackers tactics बदलते हैं, software dependencies बदलती हैं, logistics chains बदलती हैं और regulation बदलता है। सही उत्तर “just in case” indefinite collection नहीं है। वह एक living data map है, जिसके purposes, processors और deletion evidence को दुनिया के बदलने के साथ review किया जाता है।

अक्सर पूछे जाने वाले प्रश्न

क्या अगस्त 2026 में Trezor का हार्डवेयर hack हुआ था?

Trezor का कहना है कि नहीं। उसका 13 अगस्त का नोटिस ShipMonk में अनधिकृत पहुँच और ग्राहक ऑर्डर-पूर्ति डेटा के उजागर होने से संबंधित था। Trezor ने कहा कि उसके सिस्टम, हार्डवेयर वॉलेट, निजी कुंजियाँ और बैकअप प्रभावित नहीं हुए। Trezor के नोटिस ने exploit का नाम नहीं दिया; BleepingComputer ने बाद में बताया कि ShipMonk के ईमेल ने पहुँच को Metabase vulnerability से जोड़ा, जिसे Metabase ने CVE-2026-72898 बताया।

क्या COLDCARD घटना ग्राहक-डेटा breach थी?

COLDCARD vulnerability के संबंध में ग्राहक डेटाबेस breach स्थापित नहीं हुआ है। पुष्ट समस्या seed generation में थी: firmware integration की त्रुटि ने deterministic fallback generator को randomness देने की अनुमति दी। बाद में एक अलग phishing campaign ने घटना से जुड़ी सार्वजनिक चिंता का लाभ उठाया, लेकिन सार्वजनिक साक्ष्य यह नहीं दिखाते कि उसने Coinkite की लीक हुई ग्राहक सूची इस्तेमाल की।

Trezor और SafePal ने कौन-सी जानकारी उजागर होने की रिपोर्ट की?

Trezor ने 11,742 ग्राहकों के नाम, ईमेल, फोन नंबर और शिपिंग पते, तथा अन्य 1,947 ग्राहकों के नाम, शहर और ईमेल उजागर होने की रिपोर्ट की। SafePal ने लगभग 39,798 ग्राहकों के नाम, ईमेल, फोन नंबर, शिपिंग पते और खरीद विवरण की रिपोर्ट की। ये कंपनियों द्वारा बताई गई संख्याएँ हैं, स्वतंत्र रूप से ऑडिट किए गए कुल नहीं; और इन नोटिसों में किसी कंपनी ने वॉलेट रहस्य उजागर होने की रिपोर्ट नहीं की।

क्या GDPR हार्डवेयर-वॉलेट कंपनी से कोई डेटा न जुटाने की मांग करता है?

नहीं। जहाँ GDPR लागू होता है, वहाँ वह व्यक्तिगत डेटा को किसी निर्धारित उद्देश्य के लिए पर्याप्त, प्रासंगिक और आवश्यक सीमा तक सीमित रखने तथा आवश्यकता से अधिक समय तक न रखने की मांग करता है। वह design और default द्वारा data protection भी मांगता है। यह न्यूनतमकरण, पृथक्करण और deletion schedules का समर्थन करता है, लेकिन सार्वभौमिक zero-collection नियम नहीं बनाता।

क्या self-custody किसी प्रदाता को वित्तीय विनियमन से स्वतः छूट देती है?

नहीं। विनियामक स्थिति इस पर निर्भर करती है कि प्रदाता वास्तव में क्या करता है, जिसमें key control, signing या intervention powers, transfer या exchange services, smart-contract roles और निरंतर customer relationships शामिल हैं। केवल hardware sale विश्लेषण का फैसला नहीं करती। इसलिए MiCA, Travel Rule, AMLA, DORA या CARF से किसी छूट का दावा करने से पहले CLAVI की production feature set और contractual role की jurisdiction-specific legal review आवश्यक है।

Personal Vault के लिए zero knowledge का क्या अर्थ होना चाहिए?

Personal Vault के लिए zero knowledge को एक सटीक तकनीकी सीमा बतानी चाहिए: संचालक को उपयोगकर्ता के वॉल्ट रहस्य न तो प्राप्त होने चाहिए, न उन्हें पुनर्प्राप्त करने में सक्षम होना चाहिए। इसका उपयोग यह संकेत देने के लिए नहीं होना चाहिए कि संचालित कंपनी के पास order, invoice, support या compliance records नहीं होते। उन व्यावसायिक रिकॉर्ड के लिए अलग उद्देश्य, access controls और retention schedules चाहिए।

Logistics और अन्य processors में deletion सत्यापित करना क्यों आवश्यक है?

यदि warehouse, carrier, payment processor, support platform, backup provider या marketing service में प्रतियाँ सक्रिय रहें, तो controller की deletion policy जोखिम घटा नहीं सकती। अनुबंध आवश्यक हैं, लेकिन अधिक मजबूत नियंत्रण production systems, replicas और backups में सत्यापन योग्य deletion है, जिसमें अनसुलझे orders या वैध preservation के लिए documented exceptions हों।

टिकाऊ स्थिति: वॉल्ट के कोई रहस्य नहीं, कम व्यावसायिक डेटा, अधिक साक्ष्य

सबसे सुरक्षित customer record वह है जो operator के systems में कभी प्रवेश नहीं करता। यह सिद्धांत private keys, recovery material और protected vault content पर सबसे मजबूती से लागू होना चाहिए। किसी operating company को process करनी पड़ने वाली सीमित information के लिए standard अलग, पर उतना ही कठोर है: कम collect करें, purposes अलग रखें, records expire करें, downstream deletion verify करें और exception document करें।

COLDCARD दिखाता है कि privacy मजबूत cryptographic implementation की जगह नहीं ले सकती। Trezor और SafePal दिखाते हैं कि commerce systems लोगों को उजागर कर सकते हैं, जबकि wallet hardware reported incident से बाहर रहता है। Personal Vault security की अधिक ईमानदार परिभाषा को secret की रक्षा करनी चाहिए, person की रक्षा करनी चाहिए और उनके बीच मौजूद data की पहचान करनी चाहिए।