Lightning Address معرّف بصيغة مستخدم@نطاق تحصل المحفظة منه على معلمات LNURL-pay ثم فاتورة BOLT 11 محددة. لا تُرسل الأموال بالبريد الإلكتروني، والاسم نفسه لا يحتفظ بأي بيتكوين.
يستخدم LUD-16 اسم username ونطاقاً، لكنه يقصر الاسم على الأحرف الصغيرة a-z والأرقام 0-9 والرموز -_.؛ ولا تُسمح علامة الجمع إلا إذا كانت الخدمة تدعم الوسوم. صياغة البريد الإلكتروني المعتادة أوسع. لذلك لا يضمن وجود صندوق بريد وجود Lightning Address، كما أن تطابق الاسم لا يثبت هوية المستلم كشخص. [Lightning Address — LUD-16] [Lightning Address — Project overview]
تجلب المحفظة المسار /.well-known/lnurlp/username من النطاق بواسطة GET عبر HTTPS، أو HTTP لخدمة onion. تأتي الاستجابة بصيغة payRequest وفق LUD-06. المهم هو النطاق الفعلي وخدمته؛ فالجزء السابق لعلامة @ ليس المفتاح العام لعقدة. [Lightning Address — LUD-16]
تقدّم الاستجابة callback وmetadata وحدود minSendable/maxSendable. يختار الدافع amount بوحدة msat؛ وكل 1000 msat تساوي ساتوشي واحداً. يعيد callback فاتورة في pr وتتحقق المحفظة من تطابق المبلغ قبل الدفع. البحث عن العنوان أو استلام فاتورة لا يعني التسوية. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
تسمح النسخة الأحدث من LUD-16 اختيارياً بصيغة @نطاق اختصاراً لـ _@نطاق، مع مسار ينتهي بـ /_. لا يلزم أن تدعمها الخدمة أو المحفظة. يُرسل +tag المدعوم ضمن المسار، ويمكن للخدمة استخدامه كبيانات وصفية text/tag. الوسم ليس مفتاح Bitcoin جديداً ولا حماية تلقائية للخصوصية. [Lightning Address — LUD-16]
يشترط LUD-16 وجود text/identifier أو text/email ضمن metadata؛ ويخص text/email عنوان بريد إلكتروني فعلياً. ويظل text/plain المطلوب في LNURL-pay إلزامياً أيضاً. قارن الاسم والوصف المعروضين بالنطاق والمستلم المقصود. ادعاء الخدمة ليس تحققاً مستقلاً من هوية إنسان. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]
يمكن للخدمة إصدار فواتير محفظتها أو استخدام خادم جسر متصل بعقدة. لذلك لا تعني الصيغة بذاتها الحفظ لدى الغير ولا الحفظ الذاتي. يحتاج الجسر إلى صلاحيات وظيفته، وليس تلقائياً إلى تحكم غير محدود بالمحفظة. ومن يتحكم في endpoint يستطيع التأثير في الفاتورة التي يتلقاها الدافع. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]
قد تدفع المحفظة إلى Lightning Address من دون أن توفر للمستخدمين عنواناً خاصاً بهم. يتطلب الاستلام خدمة ويب عاملة وإصدار فاتورة والقدرة على قبول الدفع. لا يخلق الاسم المقروء سيولة واردة من تلقاء نفسه. وقد تكشف الاستعلامات المتكررة للمزوّد هوية الوجهة وتوقيت الطلبات. [Lightning Address — Implementation guide]
يتيح النطاق الشخصي إعادة توجيه endpoint إلى خادم آخر؛ ويوثّق BTCPay مثلاً HTTP 301. أما في نطاق يملكه غيرك، فيعتمد الاحتفاظ بالاسم على المزوّد. لا تستعيد عبارة البذرة التحكم في DNS أو الشهادات أو ربط الحسابات. بعد تغيير الخدمة، تحقّق مجدداً من البحث والفاتورة المستهدفة والاستلام؛ ولا تفترض تحديث جهات الاتصال القديمة تلقائياً. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
للحصول على صورة أوضح، اقرأ هذا المدخل مع LNURL, BOLT 11, Lightning Network, Inbound Liquidity, الحفظ الذاتي, خصوصية Bitcoin. تشير إلى هذا المدخل أيضًا LNURL, Inbound Liquidity, Confirmo, Strike.