How do you handle matching token id to metadata on forks or re-orgs?

Smart Contracts
1

Hi everybody

I hope i am not only one asked this important question.

I am talking specifically for ERC721PresetMinterPauserAutoId contract.

Think that you use auto id strategy when minting token. Think that tx1, tx2, tx3 transactions from a,b,c users are mined in this order so token id will be

tx1 : token id = 1 ,owner = a , token uri = example.com/tokens/1, metadata = m1
tx2 : token id = 2 , owner = b, token uri = example.com/tokens/2, metadata = m2
tx3 : token id = 3 , owner = c , token uri = example.com/tokens/3, metadata = m3

Suddenly re-orgs happens on chain so order of tx change as tx3, tx2, tx1 in this case

tx3 : token id = 1 ,owner = c , token uri = example.com/tokens/1, metadata = m1
tx2 : token id = 2 , owner = b, token uri = example.com/tokens/2, metadata = m2
tx1 : token id = 3 , owner = a , token uri = example.com/tokens/3, metadata = m3

As you can see that chain re-organized fine but off-chain metadata on server points to wrong token id.
If a,b,c owners are exactly same so nothing wrong in here because the owner will have 1,2,3 token id numbers in any case and tokens will have exactly same metadata after re-org like 1 = m1,2 = m2, 3 = m3

But if a,b,c are different owners in this case there is a mismatch between tokens and metadata on server.

I hope it is clear what i am saying in here if not so let me know.
Let me know if there is well known solution to this problem.

2

If the reorg chain becomes the chain w/ the most work done, it is the "truth". Wait for more block confirmations (12?) before doing anything on your server.

3

Can you please tell me first how metadata server can recognize these changes seriously. Because metadata server saved m1 metadata with 1 numbered token id. As far as i understand metadata server has to collectect transaction id to handle changes on chain.

What do you think ?

4

I'm not quite sure I understand what you mean... The metadata server should only store metadata. It is the NFT contract that contains information about which token ID should belong w/ which metadata.

5

In the ERC721PresetMinterPauserAutoId example, when you make a call for mint method, you don't know which token id it will return when transaction mined. There is race conditions on transactions and once it is mined then you know the token id. On NFT marketplace, users mint NFT over the app and different users mint different tokens with metadata. So app takes metadata information and i guess application should wait transaction to be mined and after that obtain token id then deploy metadata information to url (baseUrl + tokenId).

Think that re-org happened and transaction this time mined and minted different token id but metadata on server points to someone else metadata because someone else minted that token id this time.

It is clear what i am saying now for you? So IMO, metadata server associate metadata url with transaction id and always observe token id and metadata url and match them in re-org happened.

IMO there is better solution, Mint method should always get metadata url as parameter so in this way that transaction will always mint the token for that url even there is a re-org on chain so in my opinion, ERC721PresetMinterPauserAutoId token id matching strategy is not good because client has to handle it always.

What do you think ?