Covenant شرط يمكنه تحديد من يحق له إنفاق البيتكوين، وكذلك الشكل الذي يجب أن يتخذه التحويل التالي. فقد يشترط مرور الأموال أولاً بمخرج له مدة انتظار. القيد جزء من قواعد إنفاق ذلك المخرج، وليس مجرد إعداد في تطبيق. وتشير Covenants إلى عائلة من البنى والمقترحات، لا إلى ميزة واحدة متاحة في كل محفظة.
تحتفظ آنا بمدخراتها في Bitcoin. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. الرصيد الظاهر في محفظتها يتكون من مخارج معاملات سابقة لم تُنفق بعد، وتسمى UTXO. يحمل كل مخرج مبلغاً وشروط إنفاقه، مكتوبة في برنامج قصير يسمى Bitcoin Script. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. قد يتطلب Multisig عدة توقيعات، ويضيف Timelock شرط انتظار. ويمكن لـcovenant أيضاً تقييد شكل المعاملة التالية، مثل المخارج التي يجب أن تنتقل إليها الأموال. حتى السارق الذي يملك المفتاح الصحيح عليه الالتزام بهذه القاعدة. لكن يجب فحص جميع مسارات الإنفاق المتاحة: إذا سمح فرع آخر بتجاوز القيد فلا يمكن الاعتماد عليه للحماية. [1] [5] [9] [11]
لنتخيل أن آنا تضع مدخراتها في خزنة ذات مهلة انتظار. لا نقصد بالخزنة جهازاً خاصاً، بل ترتيباً لقواعد الإنفاق. يستطيع مفتاحها المعتاد بدء السحب، لكن الأموال تنتقل أولاً إلى مخرج انتظار، ولا يمكن إرسالها إلى المستلم المقصود إلا بعد انقضاء المهلة. إذا بدأ السارق السحب، تستطيع آنا أثناء الانتظار استخدام مسار إنقاذ أُعد مسبقاً لنقل الأموال إلى شروط أكثر أماناً. عليها مع ذلك ملاحظة السحب والحصول على تأكيد معاملة الإنقاذ في كتلة في الوقت المناسب. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. هذه ليست وسيلة لإلغاء دفعة اكتملت، ولا إنقاذاً تلقائياً دون تدخل. وتعتمد الخيارات الدقيقة على تصميم الخزنة. [6] [10]
قد لا يكون وعد التطبيق بتأخير السحب سوى وعد من مشغّله. أما قاعدة سكربت Bitcoin فتفحصها العقد، وهي برامج تتحقق من المعاملات وفق قواعد الشبكة المشتركة. في بنية covenant المناسبة، يجب أن ترفض التحويل المخالف للقيد. ومن الأدوات المقترحة OP_CHECKTEMPLATEVERIFY، أو CTV، الوارد في BIP119؛ وBIP وثيقة تعرض مقترحاً يخص Bitcoin. يقارن CTV بصمة هاش لبيانات مختارة من المعاملة الجاري فحصها ببصمة محفوظة مسبقاً. يمكن فهم الهاش هنا بوصفه بصمة قصيرة للبيانات قابلة للتحقق. تغيير المستلم أو المبلغ المحددين يغيّر البصمة، فلا يجتاز التحويل المخالف للقالب الفحص. مجرد تسمية شيء «خزنة» داخل التطبيق لا يضمن هذا الإلزام. [2]
يربط CTV المعاملة بقالب مُعد مسبقاً، بما في ذلك مخارجها. وتُدرس أساليب أخرى أيضاً. يقترح BIP443 الأمر OP_CHECKCONTRACTVERIFY لمخارج تحمل التزاماً قابلاً للتحقق ببيانات معينة. يعني الالتزام هنا أنه لا يمكن استبدال قيمة بأخرى لاحقاً دون أن يكشف الفحص الاختلاف. قد تصف البيانات حالة عقد، مثل التوزيع الحالي لأموال مشتركة؛ ويمكن أن يحمل المخرج التالي حالة محدّثة إذا استوفت القواعد المحددة. لذلك ليس CTV وهذا المقترح اسمين للشيء نفسه. في كل تصميم، يجب معرفة ما يلزم تحديده مسبقاً، وما يمكن تغييره لاحقاً، وما الأدوات الإضافية التي تحتاج إليها البنية كاملة. [2] [7]
يمكن للبناء التكراري أن يشترط حمل المخرج التالي للقيد مرة أخرى. فتستمر القاعدة عبر عدة معاملات، مثلاً أثناء تغيّر حالة عقد تدريجياً. لا يعني ذلك حلقة لا تنتهي عند التحقق من سكربت واحد. وصف Russell O’Connor وMarta Piekarska هذه البنى في بحثهما عام 2017؛ وإمكان التكرار يتوقف على المقترح المحدد. [3]
يمكن إعداد بعض القيود بمعاملات موقعة مسبقاً وأقفال زمنية وإدارة المفاتيح. لكن ذلك قد يتطلب محواً موثوقاً لمفتاح، أو حفظ جميع المعاملات، أو استمرار التعاون. أما Multisig الذي يعتمد على رفض موقّع آخر لدفعة غير مناسبة، فيضيف افتراض ثقة مختلفاً. تشابه تجربة المستخدم لا يعني تطابق طريقة فرض القواعد أو خيارات الاستعادة. [5] [6]
إلى جانب الخزائن، تُدرس مشاركة UTXO وإعداد دفعات تتوزع تسويتها على الوقت. قد يكون الهدف تقليل الحاجة إلى التعاون المستمر أو تحسين استخدام مساحة الكتل. هذا لا يعني معاملات بلا حدود أو رسوماً منخفضة مضمونة. يجب أن يشرح التصميم أيضاً خروج مشارك منفرداً، وغياب الآخرين، وتسديد الرسوم عند ازدحام الشبكة. [2] [7]
حتى 17 أكتوبر 2026، يحمل BIP119 وBIP443 حالة Draft، أي مقترحين ما زالا قيد التطوير. أما BIP345 الأقدم، OP_VAULT، فحالته Closed، ويذكر BIP443 بديلاً مقترحاً. إغلاق هذه الوثيقة لا يعني انتهاء أبحاث الخزائن. وبالمثل، لا يعني منح رقم BIP أن الشبكة تبنّت التغيير. يمكن لشبكة اختبار أو محفظة تجريبية عرض ميزة بينما تبقى قواعد شبكة Bitcoin الرئيسية، mainnet، دون تغيير. لذلك تحقّق من الشبكة والقواعد المستخدمة فعلياً إذا كانت خدمة ما تعرض خزنة قائمة على covenants. [6] [8]
قد يمنع قالب ضيق جداً أو خطأ في المبلغ أو السكربت أو آلية الرسوم الإنفاق المقصود. وتوسّع العمليات الجديدة أيضاً ما يجب على التنفيذ التحقق منه بأمان. لذلك تُقيّم تغييرات الإجماع وفق مواصفاتها الدقيقة وسلوكها عند الخطأ. لا يمنح covenant بحد ذاته شخصاً غريباً حق تغيير شروط UTXO الموجودة لديك بأثر رجعي. [4] [8]
في أي حل محدد، اسأل من يستطيع بدء السحب أو الإنقاذ، وكم تدوم مهلة التصرف، وهل يجب أن يراقب أحد السلسلة باستمرار. تحقّق أيضاً من النسخ الاحتياطية والرسوم وإمكان الخروج والشبكة التي يعمل عليها الحل فعلاً. قد توسّع Covenants سيطرتك على أموالك، لكن وجود الكلمة في وصف منتج لا يثبت تلك السيطرة. [3] [6]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, قواعد الإجماع, UTXO, Multisig. تشير إلى هذا المدخل أيضًا OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.