يشير Coinbase Custody إلى حفظ الأصول الرقمية للمؤسسات ضمن بيئة Coinbase. وهو موجه أساسًا للمؤسسات والعملاء المحترفين الذين يحتاجون إلى قواعد للوصول والموافقات والسجلات. تحدد الشركة المتعاقدة والمنتج المعين ما يُقدَّم. الموافقة على تعليمة في الحساب ليست تحكمًا بالمفتاح الخاص، أي البيانات السرية التي تتيح توقيع معاملة بيتكوين.
تبدأ إيفا باسم الشركة في العقد، لا بشعارها. تميز الوثائق مثلًا بين Coinbase Custody Trust Company, LLC، واختصارها CCTC، وبين Coinbase Luxembourg S.A. ويتوقف الطرف المتاح للتعاقد، ضمن عوامل أخرى، على المنتج وبلد تأسيس المؤسسة العميلة. لذلك قد تشمل العلامة الواحدة عقودًا وأنظمة قانونية وأصولًا مدعومة مختلفة. تحتاج المؤسسة إلى معرفة من يحتفظ بممتلكاتها فعلًا، وتجاه من تملك حقوقًا. ولا تعوّض صفحة عامة عن الخدمة هذه المراجعة. [1]
بحسب الوثائق، يقدم Prime Vault حفظًا منفصلًا غير متصل، تُحفظ فيه المفاتيح الخاصة خارج التشغيل المعتاد عبر الإنترنت. أما Prime Custody فهو نوع محفظة مؤسسية أوسع يربط الحفظ بالتداول والتمويل. وPrime Trading نوع آخر. لذلك يجب أن تميز إيفا بين تخزين طويل الأجل وبيئة للصفقات المتكررة. هذه ليست أسماء متبادلة لتطبيق Coinbase الشخصي. كما أن اسم المحفظة وحده لا يحدد وضعها القانوني كاملًا؛ فالمنتج والعقد والاختصاص القضائي عوامل مهمة. [2] [3]
تصف وثائق Prime Custody نموذج LSOC: تكون أصول العملاء منفصلة قانونيًا، لكنها تُجمع تشغيليًا في محافظ مشتركة تسمى omnibus. ويُثبت توزيعها بين العملاء بسجلات جهة الحفظ، لا بعنوان بلوكتشين مستقل لكل مؤسسة. لذلك لا تستطيع إيفا قراءة حصة مؤسستها مباشرة من عنوان مشترك. في المقابل، تصف وثائق Vault عناوين مخصصة. لكن وجود عنوان مخصص لا يمنح المؤسسة المفاتيح الخاصة تلقائيًا. الحق القانوني وطريقة التسجيل والقدرة على توقيع المعاملة أمور مختلفة. [3]
يمكن للمؤسسة تحديد الموافقين وحدود المبالغ والشروط الزمنية أو التحقق بالفيديو. وعندما تطلب إيفا سحبًا، قد تلزم أولًا موافقة أشخاص آخرين مخولين. تسمي الوثائق هذا الاتفاق الداخلي consensus. أما Bitcoin consensus فيتعلق بالقواعد التي تحكم صلاحية المعاملات والكتل في الشبكة؛ ولا تحل موافقة الحساب محلها. كذلك لا تعني كثرة الموافقين تلقائيًا وجود multisig على السلسلة يتحكم فيه العميل، أي شرط إنفاق يتطلب عدة تواقيع على البلوكتشين نفسه. يجب التمييز بين صلاحيات الخدمة والتحكم بمفاتيح البيتكوين. [4]
في مثالنا، يعرض الحساب 10 BTC، لكن 3 BTC محجوزة لسحب ينتظر المعالجة. يبقى 7 BTC قبل أي قيود أخرى؛ ولا يجوز عدّ المبلغ المحجوز متاحًا مرة ثانية. تميز وثائق قائمة انتظار Vault بهذه الطريقة بين الرصيد الإجمالي والمتاح. تُعالج طلبات المحفظة نفسها بحسب ترتيب تقديمها، وقد يؤخر طلب غير معتمد في المقدمة ما بعده. لذلك تتابع إيفا الإرسال الفعلي وتأكيد الشبكة، لا الموافقة وحدها. فهذه خطوات لا تحدث كلها في اللحظة نفسها. [5]
قد يساعد التأمين في أحداث معينة، لكنه ليس وعدًا بتعويض كل خسارة. تصف Coinbase تغطية جزء من الأصول الرقمية ضد سرقات محددة، وتوضح أن الخسائر قد تتجاوز تعويض التأمين. ولا تتمتع BTC بتأمين الودائع FDIC، وهو النظام الأمريكي لحماية الودائع المصرفية. لذلك تحتاج إيفا إلى الشروط والحدود والاستثناءات المتعلقة بخدمتها تحديدًا. لا يمكن تطبيق حماية النقد المصرفي على البيتكوين لمجرد ظهورهما في الواجهة نفسها. [6]
في 2 أبريل 2026، منحت OCC، الجهة الأمريكية المشرفة على البنوك الوطنية، موافقة أولية مشروطة على Coinbase National Trust Company المقترحة. ويشترط القرار إذنًا نهائيًا قبل بدء النشاط. هذه خطوة تختلف عن إعلان أن الشركة الجديدة بدأت تشغيل الخدمة فعلًا. ولا تثبت هذه الوثيقة التاريخية وحدها الوضع التشغيلي الحالي، ولا تغيّر طرف عقد إيفا. إذا كان الوضع التنظيمي مؤثرًا في القرار، فعلى المؤسسة مطابقة الوثائق الحالية مع اسم الشركة الدقيق، بدل الاكتفاء بعنوان خبر. [7]
ينبغي أن تفهم إيفا السحب مثلما تفهم الإيداع: من يطلبه، ومن يوافق، وما القيود، وكيف يُتحقق من الاستلام؟ يمكن لتحويل تجريبي صغير تتبع المسار كله من التعليمة إلى المحفظة المستقبلة. الحفظ لدى مزود ليس self-custody، أي إدارة المفاتيح ذاتيًا دون الاعتماد على موافقة جهة الحفظ. ولا يضمن وضوح الحساب أو ضبط الأدوار سحبًا فوريًا في كل الظروف. غرض هذه المراجعة هو فهم توزيع المسؤولية وشروط الخدمة قبل أن تعتمد المؤسسة على عملها. [1] [4] [5]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Prime brokerage, Counterparty risk, الحفظ الذاتي, Liabilities. تشير إلى هذا المدخل أيضًا Institutional custody.