Stacks-wallet-web: 代替可能トークンの標準特性定義のサポート（SIP 010）（小数など）

@psqは、WebウォレットでのSIP010サポートの一般的な必要性（たとえば、小数、アートワーク、記号を正しく表示する）についても言及しているので、この問題を少し広げます。

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

@markmhxかっこいい！

これらのアイテムのETAをどうにかして追跡できますか？ たとえば、アイテムがバックログにとどまる時間や、かんばんを通過するのにかかる時間などです。

良い質問。 それは@andresgalanteにお任せします😄

ウォレット（またはエクスプローラー）でsip-010トークンを完全にサポートすることは、おそらく小数点以下の桁数をサポートすることを超えて、URIとシンボルを介してアートワークをプルします。 ネイティブのftトークンの残高を提供するAPIエンドポイントに依存する代わりに、すべての情報をコントラクトを介して取得する必要があります。つまり、残高はget-balance-ofを介して取得し、転送はtransfer関数を介して行われます。ネイティブクラリティ関数に依存しています。

そうしないと、トークンが転送を行うときに他のことを行う必要がある可能性があるため、不一致が発生する可能性があります（1つの可能な例については、トークンが転送できることを確認してください）。

また、トークンはその実装でネイティブのftトークンを使用することさえできません（この場合、これを改善できる可能性があるとしても、例についてはflexrを参照してください）。 これについては、以下で詳しく説明します。

追加の難しさとして、まだ不明な点の1つは、ウォレットが、一般的な場合、アドレスが所有するすべてのSIP-010トークンをどのように見つけることができるかということです。 そのようなトークンがネイティブのftトークンを使用する場合、契約アドレスは、Get Account Balancesエンドポイント（https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance）から返されるものから推測できます。 この場合、 ::残りの値を使用して、 SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothingから契約アドレスを抽出できます。
ただし、ネイティブトークンを使用していない場合、ウォレットは、トークンと対話できるようにするために、トークンのコントラクトアドレスを手動で追加する機能（メタマスクで実行できるように）を必要とする場合があります。

また、SIP-010トークンを実装するために複数のネイティブトークンが必要になる場合がいくつか考えられるので、SIP-010トークンとネイティブトークンの間に1対1のマッピングがあると想定しないでください...

うまくいけば、これが役立つ...そして必要に応じて上記のいずれかを開発して喜んでいるでしょう。

@philipdesmedt現時点ではボードの速度を見積もることはできませんが、この問題の設計フェーズからすぐに開始できます。今週は、他のタスクよりも優先するロードマップに取り組んでいます。

@psq

うまくいけば、これが役立つ...そして必要に応じて上記のいずれかを開発して喜んでいるでしょう。

デザインの準備ができたら、これは自分で実装したいと思う人でしょうか？

デザインの準備ができたら、これは自分で実装したいと思う人でしょうか？

言葉の選択が悪い、「開発する」とは、必要に応じてさらに説明することを意味しました

これがTokensoftによるxBTCの潜在的な立ち上げに影響を与えるという点でチャイムを鳴らしたかった。

@GinaAbramsはxBTCを見て興奮しています！

私が推測するマイクロ宗派のトークンを具体的に起動しない限り、これはすべての代替可能なトークンの起動に影響を与えると思います

@GinaAbrams Tokensoftがリリースに必要とする標準の特定の側面はありますか？

Webウォレットからsip-010トークンを転送しようとしても機能しないことを確認しました。 のエラー

指定したコントラクトにはtransfer関数がありません。

予想どおり、伝達関数のシグネチャが異なることを前提としています。

また、 PostConditions.allow設定したときに表示されるメッセージは、 PostConditions.denyを含む事後条件の空の配列がある場合と同じであり、混乱を招いたり、誤解を招いたりします。

PostConditions.allowを設定したときに表示されるメッセージは、PostConditions.denyで事後条件の空の配列を持っているのと同じであり、混乱を招いたり、誤解を招いたりします。

これは、パッチを適用するための無関係なUXの問題のように思われますか？ もしそうなら、それのために問題を開くことを気にしますか？

PostConditions.allowを設定したときに表示されるメッセージは、PostConditions.denyで事後条件の空の配列を持っているのと同じであり、混乱を招いたり、誤解を招いたりします。

これは、パッチを適用するための無関係なUXの問題のように思われますか？ もしそうなら、それのために問題を開くことを気にしますか？

＃1120として追加