Stacks-wallet-web: Support Standard Trait Definition for Fungible Tokens (SIP 010) (e.g. decimals)

@psq has also mentioned a general need here for SIP010 support in the web wallet (e.g. showing decimals, artwork and symbols correctly) so I'll widen this issue a bit.

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

@markmhx cool!

can we track the ETA of these items somehow? e.g. how long does an item stay in backlog and how long does it take to move through the kanban?

Good question. I'll leave that one to @andresgalante 😄

Fully supporting sip-010 tokens in a wallet (or the explorer) probably goes beyond supporting the number of decimals, pulling the artwork via the uri and the symbol. Instead of relying of the api endpoints that provide balances for native ft-tokens, all information should be retrieved via the contract, i.e. the balance via get-balance-of, and transfers made via the transfer function instead of relying on the native clarity function.

Failure to do so will likely cause discrepancies as the token may need to do other things when doing a transfer (check that it can be transferred for 1 possible example).

And a token may not even use a native ft-token in its implementation (see flexr for an example, even if maybe this could be improved in this case). More on this below.

As an added difficulty, one thing that is yet unclear, is how the wallets can, in the general case, find all SIP-010 tokens owned by an address. If such a token uses a native ft-token, the contract address can be inferred by what is returned from the Get Account Balances endpoint (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance). In this case, the contract address can be extracted from SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing by using the value left of ::.
However, if it is not using a native token, the wallet may require the ability to manually add the token's contract address (like you can do in metamask) in order to be able to interact with the token.

And I can think of a few cases where a SIP-010 token would require more than one native token to implement, so don't assume there is a one to one mapping between a SIP-010 token and native tokens...

Hopefully, this helps... and would be happy to develop any of the above if needed.

@philipdesmedt I can't estimate the speed of our board at the moment, but we can start with the design phase of this issue soon and we are working this week on the roadmap to prioritize it over other tasks.

@psq

Hopefully, this helps... and would be happy to develop any of the above if needed.

Once we have the designs ready, would this be someone that might want to implement yourself?

Once we have the designs ready, would this be someone that might want to implement yourself?

poor choice of word, by "develop", I meant explain further if needed

Wanted to chime in that this impacts a potential launch of xBTC by Tokensoft.

@GinaAbrams excited to see xBTC!

I think this impacts the launch of every fungible token, unless you specifically launch a micro-denominated token I guess

@GinaAbrams Are there any particular aspects of the standard required by Tokensoft for launch?

confirmed that trying to transfer a sip-010 token from the web wallet does not work. Errors with

The contract you specified does not have a transfer function.

as expected, as it assumes the transfer function signature is different.

Also, the message you get when setting PostConditions.allow is the same as having an empty array of postconditions with PostConditions.deny, which is confusing, or misleading.

the message you get when setting PostConditions.allow is the same as having an empty array of postconditions with PostConditions.deny, which is confusing, or misleading.

This seems like an unrelated UX problem for us to patch? If so, mind opening an issue for it?

the message you get when setting PostConditions.allow is the same as having an empty array of postconditions with PostConditions.deny, which is confusing, or misleading.

This seems like an unrelated UX problem for us to patch? If so, mind opening an issue for it?

added as #1120