Stacks-wallet-web: دعم تعريف السمات القياسي للرموز القابلة للفطريات (SIP 010) (مثل الكسور العشرية)

تم إنشاؤها على ١٥ مارس ٢٠٢١  ·  12تعليقات  ·  مصدر: blockstack/stacks-wallet-web

عند تنفيذ رمز قابل للاستبدال بعدد معين من الكسور العشرية (على سبيل المثال 6) ، فإنه يعرض حاليًا المبلغ بالكامل في Stacks Web Wallet. على سبيل المثال ، بالنسبة لعملة مستقرة xUSD أقوم بتطبيقها ، أحصل على ما يلي:
image

في هذه الحالة ، لدي 822.82 xUSD في محفظتي ، لكنها تظهر 82282000 (أي 6 أرقام عشرية). سيتبع هذا الرمز المميز القابل للاستبدال معيار SRC20 الذي تم تفعيله قريبًا (https://github.com/stacksgov/sips/pull/5/files) ، لذلك سيكون اقتراحي هو التحقق مما إذا كانت هذه السمة "القياسية" قد تم تنفيذها واستخدام decimals هناك لتصورها ومعالجتها.

enhancement ft

التعليق الأكثر فائدة

GinaAbrams متحمس لرؤية xBTC!

أعتقد أن هذا سيؤثر على إطلاق كل رمز مميز قابل للاستبدال ، ما لم تقم على وجه التحديد بإطلاق رمز مميز ذو فئة صغيرة أعتقد

ال 12 كومينتر

ذكرpsq أيضًا حاجة عامة هنا لدعم SIP010 في محفظة الويب (على سبيل المثال ، إظهار الكسور العشرية والأعمال الفنية والرموز بشكل صحيح) لذلك سأقوم بتوسيع هذه المشكلة قليلاً.

https://github.com/stacksgov/sips/blob/hstove-feat/sip-10-ft/sips/sip-010/sip-010-fungible-token-standard.md

تضمين التغريدة

هل يمكننا تتبع الوقت المقدر للوصول لهذه العناصر بطريقة أو بأخرى؟ على سبيل المثال ، ما هي المدة التي يظل فيها العنصر في حالة تراكم وكم من الوقت يستغرق التنقل خلال كانبان؟

سؤال جيد. سأترك ذلك لـ andresgalante 😄

ربما يتجاوز الدعم الكامل لرموز sip-010 في المحفظة (أو المستكشف) دعم عدد الكسور العشرية ، وسحب العمل الفني عبر uri والرمز. بدلاً من الاعتماد على نقاط نهاية api التي توفر أرصدة لـ ft-tokens الأصلية ، يجب استرداد جميع المعلومات عبر العقد ، أي الرصيد عبر get-balance-of ، والتحويلات التي تتم عبر الوظيفة transfer بدلاً من بالاعتماد على وظيفة الوضوح الأصلية.

من المحتمل أن يؤدي عدم القيام بذلك إلى حدوث تناقضات حيث قد يحتاج الرمز المميز إلى القيام بأشياء أخرى عند إجراء تحويل (تحقق من إمكانية نقله لمثال واحد محتمل).

وقد لا يستخدم الرمز المميز حتى رمز ft-token الأصلي في تنفيذه (انظر flexr للحصول على مثال ، حتى لو كان من الممكن تحسين ذلك في هذه الحالة). المزيد عن هذا أدناه.

كصعوبة إضافية ، هناك شيء واحد غير واضح حتى الآن ، وهو كيف يمكن للمحافظ ، في الحالة العامة ، العثور على جميع رموز SIP-010 التي يمتلكها عنوان. إذا كان هذا الرمز المميز يستخدم رمز ft-token أصلي ، فيمكن الاستدلال على عنوان العقد من خلال ما يتم إرجاعه من نقطة نهاية Get Account Balances (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance). في هذه الحالة ، يمكن استخراج عنوان العقد من SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing باستخدام القيمة المتبقية :: .
ومع ذلك ، إذا لم تكن تستخدم رمزًا أصليًا ، فقد تتطلب المحفظة القدرة على إضافة عنوان عقد الرمز المميز يدويًا (كما يمكنك القيام به في metamask) حتى تتمكن من التفاعل مع الرمز المميز.

ويمكنني التفكير في بعض الحالات التي يتطلب فيها رمز SIP-010 أكثر من رمز أصلي واحد للتنفيذ ، لذلك لا تفترض أن هناك تعيينًا واحدًا لواحد بين رمز SIP-010 والرموز الأصلية ...

نأمل أن يساعد هذا ... ويسعدنا تطوير أي مما سبق إذا لزم الأمر.

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

psq

نأمل أن يساعد هذا ... ويسعدنا تطوير أي مما سبق إذا لزم الأمر.

بمجرد أن تكون لدينا التصميمات جاهزة ، هل سيكون هذا الشخص الذي قد يرغب في تنفيذ نفسك؟

بمجرد أن تكون لدينا التصميمات جاهزة ، هل سيكون هذا الشخص الذي قد يرغب في تنفيذ نفسك؟

سوء اختيار الكلمة ، من خلال "تطوير" ، كنت أعني المزيد من التوضيح إذا لزم الأمر

أردت أن تتناغم مع أن هذا يؤثر على الإطلاق المحتمل لـ xBTC بواسطة Tokensoft.

GinaAbrams متحمس لرؤية xBTC!

أعتقد أن هذا سيؤثر على إطلاق كل رمز مميز قابل للاستبدال ، ما لم تقم على وجه التحديد بإطلاق رمز مميز ذو فئة صغيرة أعتقد

GinaAbrams هل هناك جوانب معينة للمعيار المطلوب بواسطة Tokensoft للإطلاق؟

أكد أن محاولة نقل رمز sip-010 من محفظة الويب لا يعمل. أخطاء في

العقد الذي حددته لا يحتوي على وظيفة transfer .

كما هو متوقع ، حيث يفترض أن توقيع وظيفة النقل مختلف.

أيضًا ، الرسالة التي تتلقاها عند تعيين PostConditions.allow هي نفسها وجود مصفوفة فارغة من الشروط اللاحقة مع PostConditions.deny ، وهو أمر محير أو مضلل.

الرسالة التي تتلقاها عند تعيين PostConditions.allow هي نفسها وجود مصفوفة فارغة من الشروط اللاحقة مع PostConditions.deny ، وهو أمر محير أو مضلل.

هذا يبدو وكأنه مشكلة UX غير ذات صلة بالنسبة لنا لتصحيحها؟ إذا كان الأمر كذلك ، هل تمانع في فتح قضية لها؟

الرسالة التي تتلقاها عند تعيين PostConditions.allow هي نفسها وجود مصفوفة فارغة من الشروط اللاحقة مع PostConditions.deny ، وهو أمر محير أو مضلل.

هذا يبدو وكأنه مشكلة UX غير ذات صلة بالنسبة لنا لتصحيحها؟ إذا كان الأمر كذلك ، هل تمانع في فتح قضية لها؟

تمت الإضافة كـ # 1120

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات