Transaction confirmation/Token name issue

[kjchiang3]

Issue with updated token names for tokens launched on Stackswap's Token Launchpad.
Issue is occurring on v3.7.1

Tokens launched from the Launchpad before the last update are showing correctly, but tokens launched since then are showing as "TOK" ticker instead of the updated ticker.

e.g. SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.tokensoft-token-v4ktqebauw9
This token should be displaying a ZERO ticker.

[andresgalante]

Thanks for the report. We have a release ready for tomorrow that solves it.

[janniks]

This might be related to an issue in stacks.js (hirosystems/stacks.js#1230) username validation, which fails to fully authenticate users. The latest fixes are released in @stacks/[email protected], @stacks/[email protected], @stacks/[email protected]

[timstackblock]

@andresgalante @janniks this issue you are mentioning above was something I noticed during testing but is not related to the issue with the token name.

I was able to reproduce this and I do not see the token name listed in the wallet or in explorer.

I created a token called Tim Test Token the ticker it TTT, it looks good on stackswap but is very hard to follow in the wallet.
Here are screenshots of the token

It shows the TTT ticker but when I look in the wallet I do not see anything that related to TTT. I have Stackables and LTO liquidity tokens. I am guessing these represent TTT but do not show the TTT ticker

[Eshwari007]

The latest fix @stacks/[email protected] fixes the issue of an account with bns name to sign in successfully to https://app.stackswap.org/swap, this however failed in v 3.7.1 testing.
cc @andresgalante @janniks

[kjchiang3]

Would it just be an issue of updating the token metadata on the DB about once a day?

[kjchiang3]

zero : SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.tokensoft-token-v4ktqebauw9
wagmi : SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.tokensoft-token-v4ka1lgcc8y

In the above examples, Zero token is not updating to new values, but WAGMI token shows up as expected.

[markmhendrickson]

@andresgalante Let's assign to a dev?

[diwakergupta]

zero : SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.tokensoft-token-v4ktqebauw9 wagmi : SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.tokensoft-token-v4ka1lgcc8y

In the above examples, Zero token is not updating to new values, but WAGMI token shows up as expected.

So neither the zero token nor the wagmi token actually define the relevant SIP-010 properties:

(define-data-var token-name (string-ascii 32) "")
(define-data-var token-symbol (string-ascii 32) "")
(define-data-var token-decimals uint u0)

But the API returns this for the wagmi metadata

{
  "token_uri": "https://jsonkeeper.com/b/EO9R",
  "name": "WAGMI",
  "description": "WE'RE ALL GONNA MAKE IT",
  "image_uri": "https://stacks-api.imgix.net/https%3A%2F%2Fi.postimg.cc%2FWzh48MdD%2FWagmi.png?s=29d469371f8d450895534f1b4b70256b",
  "image_canonical_uri": "https://i.postimg.cc/Wzh48MdD/Wagmi.png",
  "symbol": "WAGMI",
  "decimals": 4,
  "tx_id": "0x1aad6a5d2559642fa9af74844b4478d9695ba884a404ba6f60102b70019aa413",
  "sender_address": "SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275"
}

And this for the zero token:

{
  "token_uri": "https://stackswap-launchpad.s3.amazonaws.com/14c2a187-9e69-4682-bd93-1e59155978e0.json",
  "name": "Zero Authority DAO",
  "description": "",
  "image_uri": "",
  "image_canonical_uri": "",
  "symbol": "ZERO",
  "decimals": 6,
  "tx_id": "0x735598041387d188d0c5238132ef070a4e05fe9a9394282e706c95b020f68613",
  "sender_address": "SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275"
}

So API is returning the correct metadata for both tokens -- @kjchiang3 can you confirm?

Separately, given the contracts don't define these properties, I don't quite understand where the API is picking up the FT metadata. @zone117x @rafaelcr could you chime in?

[kjchiang3]

yes @diwakergupta, the metadata is correct.

[markmhendrickson]

@timstackblock can you provide the Explorer URL of your TTT token here so we can check to see if the API is returning its data fine?

[kjchiang3]

@timstackblock is this your test token?
SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.liquidity-token-v5ke9jtb4ij
https://explorer.stacks.co/txid/0x20cec455c4e40e5ce10813988018785209fa60c22983984bd93db4391070d53d?chain=mainnet

[markmhendrickson]

I'm getting blank symbol (and other) data from the API for wagmi, zero and liquidity-token-v5ke9jtb4ij when I try today:

@saralab @rafaelcr @zone117x Any idea why this might be intermittently different than what @diwakergupta saw above?

[markmhendrickson]

@kjchiang3 I presume that's not actually @timstackblock's TTT since it was deployed a month ago whereas Tim tested 10 days ago?

[kjchiang3]

@kjchiang3 I presume that's not actually @timstackblock's TTT since it was deployed a month ago whereas Tim tested 10 days ago?

it could be, as we deploy a template token ahead of time, then change metadata using our Launchpad. it would be easier to check through Tim's transaction history

[zone117x]

we deploy a template token ahead of time, then change metadata using our Launchpad

This is not a supported pattern in the API. The metadata is usually resolved when the contract is deployed. The only reason metadata for these initially-empty contracts would be in the API is from manual restarting/upgrading the service which can result in FT metadata being re-resolved.

FT authors should standardize on a method for emitting notifications when metadata is changed, e.g. in a Clarity smart contract log event. Until then, the API is not going to reliably pick up changes to FT metadata at arbitrary times.

[stackswap]

I understand this isn't what Hiro had intended at first, but considering that our project for 1-step token generation grant had been approved last year(stacksgov/grants-program#173), I do believe it is imperative to have this simple functionality included. Can't you just update your server on token metadata once a day or so? This cannot be a difficult job.

[sabbyanandan]

After talking to @rafaelcr and @zone117x, we can't think of a workaround that doesn't deviate from what the API already represents and its design principles. While we can attempt to flag specific contract metadata for reprocessing in the database, that manual chore is not scalable. It still won't cover this scenario for Devs relying on either self or other hosted API instances.

I was exploring to see if we can add an on-demand API to flag contract metadata for reprocessing, but that would be Hiro-specific. It doesn't promote a standard way of accomplishing this from the Stacks ecosystem perspective.

While digging further, I was kindly pointed to hirosystems/stacks-blockchain-api/pull/576, and this comment, in particular, the details captured in that discussion are worth reading if you aren't familiar with the initial Metadata design. The ideal solution is to standardize the event payload representing the contract metadata change. And the API can react to the change and do the right thing behind the scenes to reprocess the metadata.

All that said, there are a couple of concrete next steps that @zone117x and @rafaelcr have proposed.

1- We are going to be drafting a SIP on dynamic metadata change events.
2- To build on (1), we will implement the API scaffolding to react to, and process metadata change events.

[markmhendrickson]

I'm closing this out as a wallet-specific issue since it appears that any next steps will take place on the SIP or API side. 🙏

[rafaelcr]

FYI @stackswap @markmhx @kjchiang3 a draft SIP to solve metadata updates is now submitted stacksgov/sips#72