واجهة تدقيق الرموز في المهارة الرسمية تكذب بشأن قيمة riskLevel.
الواجهة موجودة على web3.binance.com ضمن /bapi/defi/v1/public/wallet-direct/security/token/audit، وتستخدم POST، وتتطلب ثلاثة حقول: binanceChainId وcontractAddress وrequestId. لا تقبل معرّفات السلاسل سوى أربعة: BSC بقيمة 56، وإيثريوم بقيمة 1، وBase بقيمة 8453، وSolana بقيمة CT_501. يجب أن يكون requestId معرّف UUID جديدًا في كل مرة، وإلا فستحصل مباشرةً على HTTP 400.
المشكلة في الحقول المعادة. أرسلت عنوانًا زائفًا بطول غير صحيح، فكانت قيمة hasResult هي false، لكن حقل المخاطر ظل يعرض LOW، وكانت قيمة riskLevel هي -1. وحدث الأمر نفسه عند إدخال chainId بقيمة 999: أصبحت isSupported بقيمة false، لكن LOW ظلت ظاهرة. إذا اعتمدت على حقل riskLevel وحده، فقد تظن أن العملة التي تعذّر العثور عليها منخفضة المخاطر.
الترتيب الصحيح هو التحقق من hasResult وisSupported معًا، والدخول إلى riskLevel فقط عندما تكون قيمتهما true.
جرّبت ذلك على عقد العملة المستقرة صاحبة أكبر حجم تداول على BSC (0x55d398…7955)، فعادت قيمة riskLevel وهي 3، ويعرض التعداد MID. لم يظهر سوى عنصر واحد مطابق: Mintable Detected، بدرجة CAUTION. وفي extraInfo، كانت ضريبتا الشراء والبيع فيه تساويان 0.
لذا لا تعتبر الدرجة الإجمالية حكمًا نهائيًا. تحقّق من عناصر riskItems التي تكون قيمة isHit فيها true، ثم راجع ما إذا كان riskType لذلك العنصر هو RISK أم CAUTION. أما حدود معدلات الضرائب الثلاثة، فينص المصدر الرسمي على أن ما يزيد على 10% خطير، وما بين 5% و10% تحذيري، وما يقل عن 5% طبيعي.
كما أنني أنقل إخلاء المسؤولية هذا: انخفاض المخاطر لا يعني أن العملة آمنة. التدقيق ليس سوى لقطة في لحظة معينة؛ إذ يظل بإمكان فريق المشروع تعديل العقد أو سحب السيولة بعد أن تبدأ أنت بالتعامل.
صيغة الطلب موضّحة في المهارة الرسمية query-token-audit. انسخها وأرسلها إلى مساعد الذكاء الاصطناعي الذي تستخدمه لتشغيلها. وطريقتي باختصار: أجرِ التدقيق مرة قبل تبديل العملة، وتخلَّ عنها إذا كانت قيمة hasResult أو isSupported هي false.
#中本聪国际社区Baoluo币商资本 #币安推出BinanceIntelligence #币安 #ساحة_بينانس
الواجهة موجودة على web3.binance.com ضمن /bapi/defi/v1/public/wallet-direct/security/token/audit، وتستخدم POST، وتتطلب ثلاثة حقول: binanceChainId وcontractAddress وrequestId. لا تقبل معرّفات السلاسل سوى أربعة: BSC بقيمة 56، وإيثريوم بقيمة 1، وBase بقيمة 8453، وSolana بقيمة CT_501. يجب أن يكون requestId معرّف UUID جديدًا في كل مرة، وإلا فستحصل مباشرةً على HTTP 400.
المشكلة في الحقول المعادة. أرسلت عنوانًا زائفًا بطول غير صحيح، فكانت قيمة hasResult هي false، لكن حقل المخاطر ظل يعرض LOW، وكانت قيمة riskLevel هي -1. وحدث الأمر نفسه عند إدخال chainId بقيمة 999: أصبحت isSupported بقيمة false، لكن LOW ظلت ظاهرة. إذا اعتمدت على حقل riskLevel وحده، فقد تظن أن العملة التي تعذّر العثور عليها منخفضة المخاطر.
الترتيب الصحيح هو التحقق من hasResult وisSupported معًا، والدخول إلى riskLevel فقط عندما تكون قيمتهما true.
جرّبت ذلك على عقد العملة المستقرة صاحبة أكبر حجم تداول على BSC (0x55d398…7955)، فعادت قيمة riskLevel وهي 3، ويعرض التعداد MID. لم يظهر سوى عنصر واحد مطابق: Mintable Detected، بدرجة CAUTION. وفي extraInfo، كانت ضريبتا الشراء والبيع فيه تساويان 0.
لذا لا تعتبر الدرجة الإجمالية حكمًا نهائيًا. تحقّق من عناصر riskItems التي تكون قيمة isHit فيها true، ثم راجع ما إذا كان riskType لذلك العنصر هو RISK أم CAUTION. أما حدود معدلات الضرائب الثلاثة، فينص المصدر الرسمي على أن ما يزيد على 10% خطير، وما بين 5% و10% تحذيري، وما يقل عن 5% طبيعي.
كما أنني أنقل إخلاء المسؤولية هذا: انخفاض المخاطر لا يعني أن العملة آمنة. التدقيق ليس سوى لقطة في لحظة معينة؛ إذ يظل بإمكان فريق المشروع تعديل العقد أو سحب السيولة بعد أن تبدأ أنت بالتعامل.
صيغة الطلب موضّحة في المهارة الرسمية query-token-audit. انسخها وأرسلها إلى مساعد الذكاء الاصطناعي الذي تستخدمه لتشغيلها. وطريقتي باختصار: أجرِ التدقيق مرة قبل تبديل العملة، وتخلَّ عنها إذا كانت قيمة hasResult أو isSupported هي false.
#中本聪国际社区Baoluo币商资本 #币安推出BinanceIntelligence #币安 #ساحة_بينانس