---
title: "مخاطر توقيع Permit2"
description: "يفصل Permit2 بين حدود الإنفاق القابلة لإعادة الاستخدام والتحويلات ذات التوقيع أحادي الاستخدام؛ ويتطلب التوقيع الآمن التحقق الدقيق من النشر والنطاق والجهة المخولة بالإنفاق والمستلم والمبلغ والعدد الفريد والموعد النهائي والشاهد وبيانات استدعاء التنفيذ."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# مخاطر توقيع Permit2

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

يجمع Permit2 نظامين مختلفين للتفويض. يخزن `AllowanceTransfer` حدا قابلا لإعادة الاستخدام مرتبطا بالمالك والرمز والجهة المخولة بالإنفاق، مع مبلغ وتاريخ انتهاء وعدد فريد مرتب. أما `SignatureTransfer` فيستهلك حدا أقصى موقعا لمرة واحدة باستخدام عدد فريد في خريطة بتات غير مرتبة، ولا ينشئ حدا دائما للجهة المخولة بالإنفاق. ويظل النظامان معتمدين على حد ERC-20 الذي يمنحه مالك الرمز لعقد Permit2.

يمكن لتوقيع لا يتطلب من صاحبه دفع الغاز أن يحرك الأصول عندما يدفع المنفذ أو المرحل تكلفة التنفيذ. تحقق من السلسلة الدقيقة وشفرة Permit2 المنشورة ونطاق EIP-712 والوحدة والرمز والجهة المخولة بالإنفاق والحد الأقصى الموقع وبيانات المستلم في الاستدعاء والعدد الفريد والمواعيد. شرعية عقد Permit2 لا تجعل جهة إنفاق أو مستلما أو موجها أو شاهدا خبيثا آمنا.

<a id="mechanism"></a>

## آلية العمل

1. ثبّت `chainId` والشبكة وعنوان `verifyingContract` الخاص بـ Permit2 وشفرة التشغيل المنشورة وعنوان الرمز ووحداته العشرية ونوع محفظة المالك والتطبيق المقصود. استخدم سجلا رسميا للنشر؛ فالعنوان أو الاسم المألوف لا يكفي.
2. اقرأ حد ERC-20 الصاعد من المالك إلى Permit2 والرصيد. حدد هل الموافقة محدودة أم غير محدودة وسلوك التحويل الخاص بالرمز؛ فهذا السجل يبقى بعد انتهاء توقيع Permit2 أو الحد الهابط المخزن.
3. حدد المسار والنوع الأساسي الموقع بدقة: `PermitSingle` أو `PermitBatch` في AllowanceTransfer، أو `PermitTransferFrom` أو نسخته الدفعية أو نسخ الشاهد في SignatureTransfer. لا تعامل `transferFrom` على أنه النوع الموقع.
4. فك ترميز نطاق EIP-712 وكل عنصر في الرسالة. في AllowanceTransfer افحص الرمز و`uint160 amount` و`expiration` والعدد الفريد المرتب والجهة المخولة بالإنفاق و`sigDeadline`. وفي SignatureTransfer افحص الرمز والمبلغ المسموحين والعدد الفريد غير المرتب والموعد النهائي والجهة المخولة بالإنفاق المرتبطة بسياق المتصل.
5. فك بيانات استدعاء التنفيذ بصورة مستقلة. في SignatureTransfer الأساسي، يكون `SignatureTransferDetails.to` و`requestedAmount` معاملي تنفيذ لا حقلين في التصريح الأساسي الموقع؛ ولا يلزم للمبلغ المطلوب إلا ألا يتجاوز الحد الأقصى الموقع. تحقق من كل فهرس في الدفعة ومن تجزئة الشاهد وسلسلة نوعه حرفيا عند وجودهما.
6. استعلم عن العدد الفريد الحالي للحد المرتب أو عن كلمة خريطة البتات وموضع البت، ثم حاك المتصل والاستدعاء والسلسلة والحالة نفسها. طابق المستلم وأفعال الموجه وخصائص الرمز والرصيد وسجلي الحدود؛ فقد تتغير نتيجة المحاكاة بتغير الحالة أو الترتيب أو إعادة التنظيم.
7. قلل المبالغ والمدد. عند الاشتباه، احتفظ بالبيانات المهيكلة وقدم عبر مسار موثوق إلغاء الموافقة الصاعدة أو الحد الهابط أو إبطال العدد الفريد المناسب، واعتبر ذلك سباقا في مجمع المعاملات؛ انتظر التأكيد وطابق التحويلات والأرصدة والحدود وبتات الخريطة.

يحدد `sigDeadline` في AllowanceTransfer آخر وقت يستطيع فيه التصريح الموقع إنشاء الصلاحية المخزنة أو تحديثها؛ بينما يحدد `expiration` مدة إمكان إنفاق تلك الصلاحية. ويحدد الموعد النهائي في SignatureTransfer تنفيذها الوحيد. توفر EIP-712 التجزئة المهيكلة وفصل النطاق، لا الحماية من إعادة الاستخدام ولا سلامة القصد؛ وتوفر قواعد العدد الفريد والموعد النهائي في Permit2 هذين الحدين.

في محفظة تعاقدية، تعتمد صلاحية ERC-1271 على سياسة `isValidSignature` الحالية ووحدات المحفظة وحدود التوقيع وشفرتها. أسماء المحافظ وشاشات محافظ الأجهزة المقتطعة والمحاكاة الناجحة أدلة مساعدة وليست ضمانات. ولا يؤدي قطع اتصال الواجهة إلى إلغاء أي موافقة أو توقيع.

<a id="example"></a>

## مثال

- **سجلان لحدود الإنفاق.** يبدأ حد الرمز المحدود الممنوح لـ Permit2 عند `1,000 USDC`، ويخزن `PermitSingle` حدا قدره `600 USDC` للجهة S. بعد أن تحول S مبلغ `225 USDC` يصبح المبلغ المخزن `600 - 225 = 375 USDC`، بينما يصبح الحد الصاعد القياسي المحدود `1,000 - 225 = 775 USDC`. انتهاء 375 أو إلغاؤها لا يمحو 775 تلقائيا؛ وقد تختلف الرموز غير القياسية.
- **المستلم والمبلغ في التحويل أحادي الاستخدام.** يوقع SignatureTransfer حدا أقصى `250 USDC`، وتطلب بيانات الاستدعاء تحويل `180 USDC` إلى تاجر. إذا كفى الرصيد والحد الصاعد، يمكن تنفيذ 180. ويستهلك العدد الفريد، فلا يمكن إعادة استخدام `70 USDC` المتبقية. وإذا سمت بيانات الاستدعاء مهاجما مستلما، فلا يمنع التصريح الأساسي وحده إعادة التوجيه هذه من الجهة المخولة المرتبطة.
- **خريطة البتات للأعداد غير المرتبة.** للعدد `513` تكون `wordPos = 513 >> 8 = 2` و`bitPos = 513 & 255 = 1` و`mask = 1 << 1 = 2`. يضبط التنفيذ البت 1 من الكلمة 2؛ وتفشل إعادة استخدام 513، بينما يظل العدد `512` في البت 0 مستقلا.
- **سباق الإلغاء.** حد مخزن قدره `400 USDC`. يبث المالك إلغاء إلى الصفر، لكن تحويل `300 USDC` ينفذ أولا فيبقى `100 USDC`؛ ثم يجعل الإلغاء اللاحق الباقي `0`. وصول الحد النهائي إلى صفر لا يعكس خسارة `300 USDC` المحققة، لذلك يجب مطابقة ترتيب المعاملات والأرصدة.

<a id="risks"></a>

## المخاطر

- معرف سلسلة أو نشر أو شفرة تشغيل غير صحيحة
- عقد تحقق مزيف أو غير متوقع
- الخلط بين AllowanceTransfer وSignatureTransfer
- جهة إنفاق أو متصل خبيث أو خاطئ
- اختيار المستلم عبر بيانات استدعاء التنفيذ
- اقتراب المبلغ المطلوب من الحد الأقصى الموقع
- عنوان رمز أو اسمه أو وحداته العشرية أو وحداته الخام غير صحيحة
- موافقة ERC-20 صاعدة دائمة أو غير محدودة
- مبلغ هابط أو مدة انتهاء مفرطان
- الخلط بين الموعد النهائي وموعد التوقيع والانتهاء
- عدد فريد مرتب قديم أو خاضع للسباق
- إعادة استخدام بت أو قناع إبطال مفرط الاتساع
- عدم تطابق تجزئة الشاهد أو سلسلة النوع الدقيقة
- عنصر دفعة مخفي أو مكرر أو خاطئ الفهرس
- اختلاف عرض الواجهة أو بيانات الاستدعاء عن القصد
- خسارة الإلغاء لسباق مجمع المعاملات أو MEV
- تغير وحدة ERC-1271 أو الموقع أو الحد أو الترقية
- رمز يقتطع رسوما أو يعيد تحديد الرصيد أو يوقف أو يحظر أو يستدعي رد اتصال
- تغير حالة المحاكاة أو فشلها أو إعادة التنظيم
- اعتبار تأكيد محفظة الأجهزة أو قطع الاتصال دليلا على الأمان

<a id="misconceptions"></a>

## مفاهيم خاطئة شائعة

- **التوقيع الذي لا يعرض طلب غاز لا يستطيع تحريك الرموز.** يمكن لطرف آخر دفع غاز التنفيذ.
- **عنوان Permit2 الرسمي يثبت أمان جهة الإنفاق والمستلم.** قد ينفذ Permit2 تفويضا خبيثا بأمانة.
- **ينشئ SignatureTransfer وAllowanceTransfer الصلاحية الدائمة نفسها.** الأول أحادي الاستخدام والثاني يخزن حدا قابلا لإعادة الاستخدام.
- **يلغي قطع الاتصال أو إلغاء طبقة واحدة كل المسارات والتواقيع المعلقة.** حالات الصلاحية الصاعدة والهابطة والعدد الفريد مستقلة، وتظل السباقات قائمة.
- **تثبت EIP-712 أو محفظة الأجهزة أو المحاكاة الناجحة القصد والنهائية.** يحسن كل منها الرؤية أو الاختبار، لكنه لا يغني عن التحقق من الحقول والاستدعاء والحالة المؤكدة.

<a id="related"></a>

## مواضيع ذات صلة

- [توقيع EIP-712 المهيكل](/ar/crypto/eip712-typed-signature/)
- [موافقة المحفظة](/ar/crypto/wallet-approval/)
- [توقيع المحفظة](/ar/crypto/wallet-signature/)

<a id="sources"></a>

## المصادر

- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (تم الاطلاع: 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (تم الاطلاع: 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (تم الاطلاع: 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (تم الاطلاع: 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (تم الاطلاع: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (تم الاطلاع: 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (تم الاطلاع: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (تم الاطلاع: 2026-08-13)

Source: https://wiki.fcontext.com/ar/crypto/permit2-signature-risk/index.mdx