Stacks-wallet-web: Prise en charge de la définition de trait standard pour les jetons fongibles (SIP 010) (par exemple, les décimales)

@psq a également mentionné un besoin général ici pour la prise en charge de SIP010 dans le portefeuille Web (par exemple, afficher correctement les décimales, les illustrations et les symboles), je vais donc élargir un peu ce problème.

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

@markmhx cool !

pouvons-nous suivre l'ETA de ces articles d'une manière ou d'une autre ? Par exemple, combien de temps un élément reste-t-il dans le backlog et combien de temps faut-il pour parcourir le kanban ?

Bonne question. Je laisse celui-là à @andresgalante 😄

La prise en charge complète des jetons sip-010 dans un portefeuille (ou l'explorateur) va probablement au-delà de la prise en charge du nombre de décimales, en tirant l'illustration via l'uri et le symbole. Au lieu de s'appuyer sur les points de terminaison api qui fournissent des soldes pour les ft-tokens natifs, toutes les informations doivent être récupérées via le contrat, c'est-à-dire le solde via get-balance-of , et les transferts effectués via la fonction transfer au lieu de en s'appuyant sur la fonction de clarté native.

Ne pas le faire entraînera probablement des divergences car le jeton devra peut-être faire d'autres choses lors d'un transfert (vérifiez qu'il peut être transféré pour 1 exemple possible).

Et un token peut même ne pas utiliser un ft-token natif dans son implémentation (voir flexr pour un exemple, même si cela pourrait peut-être être amélioré dans ce cas). Plus à ce sujet ci-dessous.

Comme difficulté supplémentaire, une chose qui n'est pas encore claire, c'est comment les portefeuilles peuvent, dans le cas général, trouver tous les jetons SIP-010 appartenant à une adresse. Si un tel jeton utilise un ft-token natif, l'adresse du contrat peut être déduite de ce qui est renvoyé par le point de terminaison Get Account Balances (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance). Dans ce cas, l'adresse du contrat peut être extraite de SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing en utilisant la valeur restante de :: .
Cependant, s'il n'utilise pas de jeton natif, le portefeuille peut nécessiter la possibilité d'ajouter manuellement l'adresse de contrat du jeton (comme vous pouvez le faire dans le métamasque) afin de pouvoir interagir avec le jeton.

Et je peux penser à quelques cas où un jeton SIP-010 nécessiterait plus d'un jeton natif pour être mis en œuvre, alors ne supposez pas qu'il existe un mappage un à un entre un jeton SIP-010 et des jetons natifs...

Espérons que cela aide... et nous serons heureux de développer l'un des éléments ci-dessus si nécessaire.

@philipdesmedt Je ne peux pas estimer la vitesse de notre tableau pour le moment, mais nous pouvons bientôt commencer la phase de conception de ce problème et nous travaillons cette semaine sur la feuille de route pour la prioriser par rapport aux autres tâches.

@psq

Espérons que cela aide... et nous serons heureux de développer l'un des éléments ci-dessus si nécessaire.

Une fois que nous aurons les conceptions prêtes, serait-ce quelqu'un qui voudra peut-être les mettre en œuvre vous-même ?

Une fois que nous aurons les conceptions prêtes, serait-ce quelqu'un qui voudra peut-être les mettre en œuvre vous-même ?

mauvais choix de mot, par "développer", je voulais dire expliquer davantage si besoin

Je voulais souligner que cela a un impact sur un lancement potentiel de xBTC par Tokensoft.

@GinaAbrams ravie de voir xBTC !

Je pense que cela a un impact sur le lancement de chaque jeton fongible, à moins que vous ne lanciez spécifiquement un jeton en micro-dénomination, je suppose

@GinaAbrams Y a-t-il des aspects particuliers de la norme requis par Tokensoft pour le lancement ?

a confirmé qu'essayer de transférer un jeton sip-010 à partir du portefeuille Web ne fonctionne pas. Erreurs avec

Le contrat que vous avez spécifié n'a pas de fonction transfer .

comme prévu, car il suppose que la signature de la fonction de transfert est différente.

De plus, le message que vous obtenez lorsque vous définissez PostConditions.allow est le même que d'avoir un tableau vide de postconditions avec PostConditions.deny , ce qui est déroutant ou trompeur.

le message que vous obtenez lors de la définition de PostConditions.allow est le même que d'avoir un tableau vide de postconditions avec PostConditions.deny, ce qui est déroutant ou trompeur.

Cela semble être un problème UX sans rapport que nous devons corriger ? Si oui, cela vous dérange d'ouvrir un problème pour cela?

le message que vous obtenez lors de la définition de PostConditions.allow est le même que d'avoir un tableau vide de postconditions avec PostConditions.deny, ce qui est déroutant ou trompeur.

Cela semble être un problème UX sans rapport que nous devons corriger ? Si oui, cela vous dérange d'ouvrir un problème pour cela?

ajouté comme #1120