> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# إثبات ملكية المحفظة: أداة Travel Rule

> أداة Didit المستضافة لإثبات ملكية المحفظة الرقمية عبر توقيع الرسائل أو اختبار ساتوشي أو الإقرار الذاتي، لأغراض Travel Rule.

أداة إثبات ملكية المحفظة هي صفحة مستضافة تُثبت أن أحد عملائك يتحكم في عنوان محفظة عملات رقمية محدد. بموجب لائحة نقل الأموال في الاتحاد الأوروبي (EU TFR)، يجب على VASP التحقق من ملكية المحفظة ذاتية الاستضافة (غير المستضافة) قبل صرف الأموال إليها أو منها إذا تجاوز المبلغ عتبة Sunrise. وتتيح لك الأداة جمع هذا الإثبات دون أن تبني تدفقات التوقيع بنفسك.

يؤدي الإثبات المُتحقَّق منه إلى تعيين قيمة [إدخال دفتر عناوين المحفظة](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#دفتر-عناوين-المحافظ) المطابق إلى `is_ownership_verified: true`، مما يتيح للتحويل المرتبط [Travel Rule](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md) الخروج من `UNCONFIRMED_OWNERSHIP`.

## متى ينشئها Didit نيابةً عنك

نادراً ما تحتاج إلى إنشاء جلسة بنفسك.
عندما تكون `auto_wallet_verification` مفعّلة في [إعدادات Travel Rule](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#الإعداد) الخاصة بك (وهي الإعداد الافتراضي)، ينشئ Didit تلقائياً جلسة للأداة الخاصة بإثبات ملكية المحفظة عند إنشاء المعاملة، كلما احتاج التحويل إلى إثبات تحكّم المستخدم النهائي بالمحفظة:

* يكون التحويل في `UNCONFIRMED_OWNERSHIP`، أي أن محفظة الطرف المقابل أُعلن أنها [ذاتية الاستضافة](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#المحافظ-ذاتية-الاستضافة-المُصرَّح-بها) عند الإرسال.
* التحويل صادر وفي `COUNTERPARTY_VASP_NOT_FOUND`، أي تعذّر تحديد أي VASP للطرف المقابل، لذا فإن إثبات الملكية هو المسار المتبقي لإتمام التحويل.

تُعاد الجلسة المنشأة تلقائياً ضمن كتلة `action_required` الخاصة بالمعاملة (`type: "wallet_ownership"`، مع `url` الذي يجب فتحه)، وتشغّلها حزم SDK تلقائياً عند [الإرسال من جهة العميل](https://docs.didit.me/ar/transaction-monitoring/sdk-transaction-submission.md#الإجراءات-المطلوبة-من-المستخدم).
لا تحصل التحويلات الواردة التي ينشئها Didit نيابةً عنك (تسجيل Sunrise، أو استعلام `TRP` وارد، أو الشق الوارد لمسار `INTERNAL`) أبداً على جلسة منشأة تلقائياً، حتى عندما تنتهي في `UNCONFIRMED_OWNERSHIP`.
أنشئ الجلسة يدوياً باستخدام `POST /v3/travel-rule/widget-session/` عندما ترغب في التحقق المسبق من محفظة قبل وجود أي تحويل، أو عندما تكون `auto_wallet_verification` معطلة، أو لأحد هذه التحويلات الواردة.

## ما الذي يُثبته

تقدم الأداة حتى أربع طرق لإثبات الملكية. ويعتمد ما يظهر منها على الطريقة التي أنشأتَ بها الجلسة، وعلى [إعدادات Travel Rule](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#الإعداد) لديك:

| الطريقة | طريقة العمل | متى تُعرض |
| - | - | - |
| `MESSAGE_SIGNING` | يوقّع العميل سلسلة تحدٍّ صادرة عن Didit بمحفظته. تدعم الطريقة محافظ EVM وSolana وBitcoin وTron (بالنسبة إلى Bitcoin: العناوين القديمة (legacy)، وSegWit المتداخل، وSegWit الأصلي، وعناوين Taproot). تتحقق Didit من التوقيع مقابل العنوان، ويُرفض التوقيع بحساب مختلف عن الحساب المراد التحقق منه، مع رسالة واضحة تطلب تبديل الحساب. كما يمكن لحسابات العقود الذكية في EVM (المحافظ الذكية وفق ERC-4337) التوقيع: تسأل Didit عقد الحساب نفسه، على السلسلة المعلنة للمحفظة، عمّا إذا كان التوقيع صالحاً (ERC-1271)، وبالنسبة إلى حساب لم يُنشر بعد تتحقق من توقيع ERC-6492 الذي تعيده المحفظة، دون نشر الحساب أو إرسال أي معاملة. تُفحص حسابات العقود الذكية على كل سلسلة EVM مدعومة. انظر [عقد التحقق من توقيع الرسالة](#عقد-التحقق-من-توقيع-الرسالة) أدناه. تُكتشف المحافظ المثبتة في متصفح العميل عبر بروتوكولي EIP-6963 وWallet Standard، فيظهر كل امتداد كخيار توقيع مستقل. أما ربط تطبيق محفظة منفصل على الهاتف، مثلاً عبر رمز QR، فغير متاح حالياً. | دائماً، لعائلات السلاسل المدعومة. |
| `SATOSHI_TEST` | يرسل العميل من محفظته مبلغاً صغيراً على السلسلة إلى عنوان إيداع تتحكم فيه. يتحقق مراقب Didit من المُرسِل (وفي حالة حساب العقد الذكي، من الحساب نفسه، حتى لو قدّم bundler وفق ERC-4337 المعاملة)، ومن المبلغ، ومن تأكيد الإيداع على السلسلة، ثم يُكمل الإثبات تلقائياً بعد تأكيده. انظر [عقد التحقق من اختبار Satoshi](#عقد-التحقق-من-اختبار-satoshi) أدناه. | فقط عند تمرير `satoshi_deposit_address` وقت الإنشاء، وكانت السلسلة من سلاسل EVM أو Bitcoin أو Solana، ولذلك لا تظهر أبداً في الجلسات المنشأة تلقائياً. |
| `SCREENSHOT` | يرفع العميل لقطة شاشة للمحفظة تُظهر العنوان (JPEG أو PNG أو WebP، بحد أقصى 10 ميغابايت). وعلى خلاف الطرق الأخرى، لا يُتحقق منها تلقائياً أبداً: يراجعها فريق الامتثال من قائمة انتظار مراجعة لقطات الشاشة ([`GET /v3/travel-rule/wallet-proofs/`](https://docs.didit.me/ar/management-api/travel-rule/list-wallet-proofs))، ويقبلها أو يرفضها ([`POST .../decision/`](https://docs.didit.me/ar/management-api/travel-rule/decide-wallet-proof))، أو يؤكد التحويل من تبويب **Travel Rule** للمعاملة في الكونسول، أو عبر [`POST .../travel-rule/ownership/`](https://docs.didit.me/ar/management-api/travel-rule/confirm-ownership) (للتحويل في حالة `UNCONFIRMED_OWNERSHIP` أو للتحويل الوارد المعلّق). | فقط عندما يكون `allow_screenshot_proof` بقيمة `true` في إعداداتك. |
| `SELF_DECLARATION` | يُقرّ العميل بالملكية دون إثبات تشفيري. وهي الملاذ الأخير حيث تتسامح الولاية القضائية مع ذلك. | فقط عندما يكون `allow_self_declaration` بقيمة `true` و[`ownership_validation_mode`](https://docs.didit.me/ar/transaction-monitoring/travel-rule#أوضاع-التحقق-من-الملكية) الخاص بك يقبل إقراراً للتحويل المرتبط: لا يُقبل أبداً في `FULL`، ويُقبل في `SIMPLIFIED` فقط إذا كانت القيمة أقل من `simplified_validation_threshold`. ويؤدي بدء طريقة لا يقبلها الوضع إلى إرجاع الاستجابة `403`. |

### عقد التحقق من توقيع الرسالة

عند إرسال التوقيع، يُعاد `200` مع `status: "VERIFIED"` بمجرد إثبات السيطرة على المحفظة.
ويُعاد `400` ويبقى الإثبات مفتوحاً، حتى يتمكن العميل من التوقيع مجدداً، مع إحدى قيم `code` التالية:

| `code` | المعنى |
| - | - |
| `SIGNATURE_INVALID` | التوقيع لا يثبت ملكية المحفظة: وقّع حساب أو مفتاح آخر، أو أن الرسالة مختلفة. وبالنسبة إلى حساب عقد ذكي، أجاب العقد بأن التوقيع ليس توقيعه. |
| `SIGNATURE_UNSUPPORTED_SCHEME` | وقّعت المحفظة بصيغة لا تتحقق منها Didit، مثل توقيع Bitcoin متعدد التوقيعات أو توقيع BIP-322 الكامل. |
| `SIGNATURE_LOOKUP_FAILED` | قد تكون المحفظة حساب عقد ذكي، ولم يمكن فحص سلسلته الآن. لا يُعد الإثبات متحققاً منه بهذه الاستجابة أبداً، والتوقيع مجدداً يعيد الفحص. |

### عقد التحقق من اختبار Satoshi

التحقق من إيداع اختبار Satoshi غير متزامن، لأن المعاملة يجب أن تُرى على السلسلة ثم تُؤكَّد.
عند إرسال `txid` الإيداع يُعاد `200` مع `status: "PENDING"` طالما لم يُؤكَّد الإيداع على السلسلة بعد، ويُحتفظ بالـ`txid` ولا يُهمل.
ويُعاد `200` مع `status: "VERIFIED"` بعد تأكيد الإيداع.
ويُعاد `400` مع `status: "REJECTED"` عند وجود إيداع خاطئ فعلاً: مُرسَل من محفظة أخرى، أو مُرسَل بمبلغ غير متوقع إلى عنوان الإيداع، أو أقدم من التحدي، أو معاملة سبق أن أثبتت السيطرة على محفظة أخرى. يُغلق الإثبات، ويمكن للعميل بدء إثبات جديد ما دامت الجلسة تملك محاولات متبقية.
ويُعاد أيضاً `200` مع `status: "PENDING"` للإيداع غير المفهرس بعد، ويُعاد `400` مع الرمز `DEPOSIT_LOOKUP_FAILED` عند فشل البحث من جهة Didit: وفي الحالتين يبقى الإثبات مفتوحاً وتواصل Didit الفحص.
ويُعاد `410` إذا انتهت نافذة الاختبار قبل رصد إيداع صالح.

بعد إرسال `txid`، تعيد مهمة خلفية فحص الإيداع المعلّق كل خمس دقائق، وتُكمل الإثبات بعد تأكيد المعاملة، فلا يحتاج العميل إلى إعادة إرسال الـ`txid`.
وعند تمرير `satoshi_deposit_address`، يُمدَّد `expires_at` الخاص بجلسة الأداة إلى 24 ساعة على الأقل، أي نافذة اختبار Satoshi، لإتاحة الوقت لتأكيد الإيداع قبل انتهاء الجلسة نفسها.

## التدفق

**1. إنشاء جلسة أداة**

استدعِ `POST /v3/travel-rule/widget-session/` مع المحفظة التي تحتاج إلى التحقق منها. يمكنك اختيارياً ربطها بتحويل ليتقدم التحويل تلقائياً بعد إثبات الملكية.

**2. فتح الرابط المُعاد**

أرسل إلى عميلك الرابط `url` من الاستجابة. يُكمل هناك إثباتاً دون الحاجة إلى حساب Didit أو مفتاح API؛ فـtoken في الرابط هو وسيلة المصادقة.

**3. رصد الاكتمال**

عند التحقق من إثبات ما، تُحدّث الأداة إدخال دفتر العناوين بوصفه موثّقاً، وإذا كانت الجلسة مرتبطة بتحويل فإنها تُقدّم ذلك التحويل إلى المرحلة التالية. راقب الحدث `travel_rule.status.updated` (للتحويلات المرتبطة) أو استعلم عن سياق الأداة بشكل دوري.

### إنشاء جلسة أداة

يربط هذا المثال الجلسة بـ[التحويل المُعلَن من محفظة ذاتية الاستضافة](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#المحافظ-ذاتية-الاستضافة-المُصرَّح-بها) من دليل Travel Rule، لذا فإن `wallet_address` هو عنوان المحفظة الوجهة لذلك التحويل.
الجلسة المرتبطة بتحويل تقبل إثباتات لمحفظة الطرف المقابل للتحويل فقط.

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/widget-session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
    "chain": "ETH",
    "holder_name": "Jane Doe",
    "vendor_data": "user-042",
    "transaction_id": "99999999-aaaa-bbbb-cccc-dddddddddddd",
    "satoshi_deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
    "callback_url": "https://yourapp.example/wallet-verified",
    "expires_in_minutes": 60
  }'
```

| الحقل | النوع | الوصف |
| - | - | - |
| `wallet_address` | string | عنوان المحفظة المراد التحقق منه. |
| `chain` | string | معرّف السلسلة لعنوان المحفظة (على سبيل المثال `ETH` أو `BTC` أو `SOL`). استخدم الرمز نفسه الذي تحمله تحويلاتك (`ETH` وليس `ethereum`): تحفظ الأداة إدخال دفتر العناوين بهذا `chain`، ولن يتطابق معه تحويل على سلسلة مختلفة. يتطلب توقيع الرسائل سلسلة يتعرّف عليها Didit. |
| `holder_name` | string | اسم حامل المحفظة، ويُستخدم لمطابقة اسم المستفيد. |
| `vendor_data` | string | معرّفك الداخلي لحامل المحفظة، ويُنقل إلى إدخال دفتر العناوين الذي يتم إنشاؤه. |
| `transaction_id` | string (uuid) | اختياري. معرّف UUID لمعاملة تحويل Travel Rule لتقديم التحويل عند التحقق من الإثبات؛ يُعيد UUID غير معروف الاستجابة `404`، ويُرفض أي إثبات لمحفظة غير محفظة الطرف المقابل للتحويل بالاستجابة `400`. اتركه دون إرسال للتحقق من المحفظة بشكل منفصل. |
| `satoshi_deposit_address` | string | اختياري. عنوان إيداع تتحكم فيه؛ يؤدي توفيره إلى تفعيل الطريقة `SATOSHI_TEST`. |
| `callback_url` | string | اختياري. رابط الاستدعاء الذي تُعيد الأداة العميل إليه بعد الإكمال. |
| `expires_in_minutes` | integer | اختياري. مدة صلاحية الرابط المُنشأ بالدقائق، من `5` إلى `10080` (الافتراضي `60`)؛ تُرفع تلقائياً إلى 24 ساعة على الأقل، أي مدة نافذة اختبار Satoshi، عند تمرير `satoshi_deposit_address`. |

```json theme={null}
{
  "widget_session_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
  "token": "3s9x...urlsafe",
  "url": "https://verify.didit.me/wallet-ownership/3s9x...urlsafe",
  "expires_at": "2026-07-07T13:00:00Z"
}
```

افتح دائماً الرابط `url` المُعاد في الاستجابة كما هو تماماً، ولا تُنشئه بنفسك.

### فتح الرابط المُعاد

> [!WARNING]
>
> **الأداة متاحة عبر الويب فقط في هذا الإصدار. افتح الرابط `url` في متصفح النظام أو في تبويب مخصص، ولا تفتحه أبداً داخل عرض webview في أي من حزم Didit SDK للجوال.**
>
> يعمل توقيع الرسائل مع المحافظ المثبّتة في متصفح العميل، والتي تكتشفها الأداة عبر بروتوكولي EIP-6963 وWallet Standard.
> ربط تطبيق محفظة منفصل على الجوال، مثلاً عبر رمز QR، غير متاح حالياً، لذا لا تنتقل الأداة إلى تطبيق آخر.
> لا يستطيع عرض webview داخل التطبيق، مثل عرض webview في Didit Web/Flutter/React Native/iOS/Android SDK، الوصول إلى محافظ متصفح العميل، لذا تُفتح الأداة هناك دون أن تتوفر للعميل وسيلة للتوقيع.
>
> على الجوال، افتح الرابط `url` عبر متصفح نظام التشغيل (`SFSafariViewController` / Chrome Custom Tabs، أو المتصفح الافتراضي) بدلاً من عرضه في webview. على الويب، تكفي علامة تبويب عادية أو نافذة منبثقة.

### رصد الاكتمال

تكشف الأداة endpoint قراءة عامة مفتاحها token؛ استعلم عنها لمعرفة التقدم، أو اعتمد على webhook عندما تكون الجلسة مرتبطة بتحويل:

```bash theme={null}
curl https://verification.didit.me/v3/travel-rule/widget/{token}/
```

```json theme={null}
{
  "vasp_name": "Origin CASP SL",
  "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
  "chain": "ETH",
  "holder_name": "Jane Doe",
  "allowed_methods": ["MESSAGE_SIGNING", "SCREENSHOT", "SATOSHI_TEST", "SELF_DECLARATION"],
  "transfer_status": "UNCONFIRMED_OWNERSHIP",
  "callback_url": "https://yourapp.example/wallet-verified",
  "expires_at": "2026-07-07T13:00:00Z",
  "completed_at": null,
  "proofs": [
    {
      "proof_id": "88888888-9999-aaaa-bbbb-cccccccccccc",
      "method": "SATOSHI_TEST",
      "status": "PENDING",
      "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
      "chain": "ETH",
      "deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
      "expected_amount": "0.000042817305521963",
      "expires_at": "2026-07-07T13:05:00.412731+00:00",
      "created_at": "2026-07-06T13:05:00.412731Z"
    }
  ],
  "customization": null
}
```

* يصبح `completed_at` غير فارغ بمجرد التحقق من إثبات.
* يحمل كل عنصر في `proofs` الحقول التي تحتاجها طريقته: يضيف إثبات `SATOSHI_TEST` الحقول `deposit_address` و`expected_amount` و`expires_at` الخاص به، ويضيف إثبات `MESSAGE_SIGNING` الحقل `challenge`، وهو النص الذي يوقّعه العميل.
* قد يبقى إثبات `SATOSHI_TEST` في الحالة `status: "PENDING"` بينما يُرصد إيداعه على السلسلة دون تأكيد، دون أن يتطلب منك أو من العميل أي إجراء. راجع [عقد التحقق من اختبار Satoshi](#عقد-التحقق-من-اختبار-satoshi) أعلاه.
* عند إنشاء الجلسة مع `transaction_id`، يؤدي التحقق من الإثبات إلى تقديم التحويل المرتبط، وفي تطبيق مباشر يُطلق webhook [`travel_rule.status.updated`](https://docs.didit.me/ar/integration/webhooks#أنواع-الأحداث). فضّل الـ webhook على الاستعلام الدوري. تُعاد الموافقة على استفسار `TRP` الوارد إلى المُرسِل، وينتقل إلى `COMPLETED` بعد تسليم هذه الموافقة. ينتقل أي تحويل آخر في `UNCONFIRMED_OWNERSHIP` (أو وارد في `ON_HOLD`) إلى `COMPLETED`، أو إلى `COUNTERPARTY_MISMATCHED_DATA` عندما لا يطابق اسم المستفيد اسم حامل المحفظة، وينتقل إيداع sunrise مُسوّى يكتمل إلى `FINISHED`. ينتقل التحويل الصادر في `COUNTERPARTY_VASP_NOT_FOUND` إلى `COMPLETED`.
* يبقى إثبات `SCREENSHOT` في الحالة `status: "PENDING"` في هذا السياق حتى بعد تأكيدك للملكية. توافق عليه عبر [`POST .../travel-rule/ownership/`](https://docs.didit.me/ar/transaction-monitoring/travel-rule#تأكيد-ملكية-المحفظة)، الذي يقبل فقط تحويلاً ينتظر تأكيد الملكية. لذلك لا يملك إثبات لقطة الشاشة مساراً للموافقة في جلسة بلا تحويل مرتبط، أو في جلسة مرتبطة بتحويل صادر في `COUNTERPARTY_VASP_NOT_FOUND`. عطّل `allow_screenshot_proof` إذا كان يجب ألا تعرض هذه الجلسات هذا الإثبات.
* بعد إثبات مرفوض تحصل الجلسة على محاولة جديدة ما دامت المحاولات متبقية. يعرض `max_attempts` و`attempts_used` و`attempts_remaining` العدد، ويحمل الإثبات المرفوض `rejection_reason`، وعندما تكون `attempts_remaining` مساوية لـ `0` تؤدي محاولة بدء إثبات آخر إلى استجابة بالرمز `409`، فتُنشئ جلسة جديدة.
* تُعيد endpoint سياق الأداة `404` لرمز غير معروف، و`410` بعد انتهاء صلاحية الجلسة دون اكتمالها.

> [!NOTE]
>
> لا توجد هنا تبعيات أحادية الاستخدام: تنتهي الأداة وخادمك إلى الحالة الدائمة نفسها (إدخال دفتر العناوين الموثّق وحالة التحويل)، لذا يمكن دائماً استعادة webhook لم يُسلَّم أو علامة تبويب أُغلقت بإعادة قراءة التحويل أو سياق الأداة.

## التعريب والعلامة التجارية

تُعرض الأداة بـ **54 لغة**، وفق مسار اللغة في الرابط (أو لغة المتصفح الافتراضية).

عند تفعيل العلامة البيضاء لتطبيقك، ترث الأداة تلقائياً العلامة التجارية لتدفق التحقق: الشعار، وألوان العلامة التجارية، وتنسيق الأزرار واللوحات، والخط المخصص، والأيقونة المفضلة، واسم تطبيقك العام في العنوان.
لا يلزم أي إعداد منفصل، إذ تنطبق على هذه الأداة التخصيصات نفسها التي ضبطتها لجلسات KYC.

يرى المستخدم الذي يعود إلى رابط مكتمل شاشة الإكمال مرة أخرى، وإذا مررت `callback_url`، فإن الأداة تعيد المستخدم إليه.
تعرض الروابط المنتهية الصلاحية شاشة انتهاء صلاحية تحمل العلامة التجارية، تطلب من المستخدم طلب رابط جديد.
أنشئ جلسة جديدة لهم باستخدام `POST /v3/travel-rule/widget-session/`: إعادة إرسال التحويل باستخدام `action: "resend"` لا تنشئ جلسة.

## الخطوات التالية

> [card] [Travel Rule](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md)
>
> دورة حياة التبادل الكاملة، والمسارات، والإعدادات، وتدفقات الاستلام.

> [card] [دفتر عناوين المحافظ](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#دفتر-عناوين-المحافظ)
>
> سجّل المحافظ التي تتحكم فيها حتى تُطابَق التحويلات الواردة معها.

> [card] [webhooks](https://docs.didit.me/ar/integration/webhooks.md)
>
> اشترك في travel\_rule.status.updated للتفاعل عندما يتسبب إثبات في انتقال تحويل إلى مرحلة لاحقة.

> [card] [SDKs الأصلية](https://docs.didit.me/ar/integration/native-sdks/overview.md)
>
> افتح عنوان URL الخاص بالأداة في متصفح النظام، لا في عرض الويب الخاص بـ SDK.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.