extension
extension copied to clipboard
leather-wallet
Display SIP-013 (semi-fungible) token balances with correct decimals
These SIP-013 tokens are not shown with the correct decimal mark. I am not sure if that is because these are SIP-013 tokens and not SIP-010 tokens?
even though in the contract 8 decimals are defined (line 16): https://explorer.alexlab.co/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.key-alex-autoalex-v1?chain=mainnet
https://github.com/hirosystems/docs/issues/110 also mentions some other examples of implemented SIP-013 tokens on mainnet.
Thanks for the report. Is the API returning data as expected for the decimals?
Thanks for the report. Is the API returning data as expected for the decimals?
No it isn't. I checked with rafael and he says this would be the API call for a fungible token (FT), not semi-fungible token (SFT): https://stacks-node-api.mainnet.stacks.co/extended/v1/tokens/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.key-alex-autoalex-v1/ft/metadata he goes on saying "we do not support semi-fungible token metadata in the API yet". So I guess we'll have to take care of that first ;-)
Merging https://github.com/hirosystems/docs/issues/110 into this PR.
What should be done to ask for Stacks API to add support for semi-fungible token (SFT) metadata?
https://github.com/stacksgov/sips/pull/42 is now in the Accepted status, and there are contracts already using the standard on mainnet.
Examples:
semi-fungible trait: https://explorer.stacks.co/txid/0x74db763fbaa66da3368e642ddac48dc5ac81f3c6e5a9b1aaf358c5745608fdde?chain=mainnet yield-alex-v1: https://explorer.stacks.co/txid/0x960dda517da8f9a71d8bf7736fc09bddfa5a7035f148387cd737eab73dcc62a6?chain=mainnet key-alex-autoalex-v1: https://explorer.stacks.co/txid/0x81dfeb1dc081781e8fe6859ebfc6c4ce68b61b2d329b294f44649115dab3ac59?chain=mainnet ytp-alex-v1: https://explorer.stacks.co/txid/0xc0283d14f4541b9c2844839fda971547c7318ec924115ce44be9109bb85bb9a7?chain=mainnet
Based on the above, it will be great to see Hiro wallet supporting SIP-013 standard.
@314159265359879 that makes sense, thanks for the additional investigation!
@rafaelcr is this API work planned for anytime soon, and is it tracked somewhere by chance? 🙏
@markmhx @314159265359879 we have major plans for the token metadata service this Q3, and I'll make sure to include support for SIP-013 tokens in the roadmap. I'm putting together some internal docs and will update here with an issue once I file one for tracking.
This issue suggests room for improvement in how various stakeholders engage with the SIP process cc/ @markmhx @sabbyanandan
It seems @314159265359879 (and perhaps others in the community) had the expectation that as SIP-013 would already be supported in the Hiro API, Wallets etc. Which seems reasonable from their perspective.
On the other hand, while SIP-013 has been under review since > 6 months ago, we (Hiro) haven't been much involved in it. In particular, I don't think any requirements from SIP-013 ever formally made their way into specific feature requests for any Hiro products, until last week.
@sabbyanandan one idea might be that we do a bi-weekly or monthly review of SIPs in flight, and anticipate support for any SIPs that reach accepted status. Open to other suggestions!
Interesting, sounds like there is an opportunity to improve. If I am luckily enough to be a SIP Resident, this can be part of the scope to explore and facilitate.
Here's a link to the draft SIP in question for good measure: https://github.com/stacksgov/sips/pull/42
@diwakergupta I may have had the expectation but also had no clue as to the work involved I was mostly looking for the reason semi-fungibles are not yet supported and how to fix it.
The idea to follow SIP's in flight to anticipate support for them, is a brilliant idea though.
SIP013 is activated and ratified what else is needed for the Hiro wallet to support these?
@rafaelcr I'm curious if SIP-013 has been factored into the more recent metadata service work by chance?
@markmhx yes that's right, SIP-013 tokens are going to be supported by the Token Metadata Service upon release 👍
Great! I imagine once we integrate the new service in support of https://github.com/hirosystems/stacks-wallet-web/issues/1028, we can also leverage it for SIP-013 support per this issue.
Note: Discussion is taking place with ALEX about how to best distinguish whether a specific SIP-013 should be treated primarily as fungible or non-fungible given its intended behavior.
Are these returned in the query for fungible-tokens or non-fungible tokens? I'm not seeing how we know to query the metadata endpoint for /ft/, /nft/, or /sft/?
Hi all, SIP-013 tokens have to be queried using this URL structure (similar to how an NFT is queried): /metadata/sft/:contract_id/:token_id, for example: https://api.hiro.so/metadata/sft/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.key-alex-autoalex-v1/77050
However, I double checked the DB and no SIP-013 contract appears to have valid SIP-016 metadata defined (or, there's a bug in the API that does not read SFT metadata correctly). If you'd like to adjust some of the metadata and have it refreshed you can emit a SIP-019 notification or let me know and I'll refresh it manually.
Also, if you think there's a bug on the API side I can definitely check it out.
Hi all, SIP-013 tokens have to be queried using this URL structure (similar to how an NFT is queried):
/metadata/sft/:contract_id/:token_id, for example: https://api.hiro.so/metadata/sft/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.key-alex-autoalex-v1/77050However, I double checked the DB and no SIP-013 contract appears to have valid SIP-016 metadata defined (or, there's a bug in the API that does not read SFT metadata correctly). If you'd like to adjust some of the metadata and have it refreshed you can emit a SIP-019 notification or let me know and I'll refresh it manually.
Also, if you think there's a bug on the API side I can definitely check it out.
Hi @rafaelcr let us review on our side and revert.