Manually updating Metadata for ERC721 Tokens / Minted with Claim app

A few reasons.

  1. You should be using this location to make the transaction;
    https://etherscan.io/address/0x7581871e1C11f85ec7F02382632B8574FAd11B22#writeContract

Link is different because you are using a different version of the claim app.

  1. Try following the latter instructions here using updateTokenURIParams:

Screen Shot 2023-04-14 at 2.11.31 PM

I tried, it didn’t work.
I got the free mint page ID and also the public mint page ID, both gave an error in the metamask

MINT: Criminals
https://apps.api.manifoldxyz.dev/public/instance/data?id=1072285936

FREE MINT HOLDERS: Criminals New Home
https://apps.api.manifoldxyz.dev/public/instance/data?id=1042186480

That error says you rejected the metamask transaction. Are you seeing an error on metamask? Are you sure you’re connected as the contract owner when issuing the command? What you entered appears correct if you are entering it here:
https://etherscan.io/address/0x7581871e1C11f85ec7F02382632B8574FAd11B22#writeContract

This looks like it should work as expected.

Please share a full screenshot which includes the url you are on and the conencted wallet so I can help you verify.

In this second link it worked, I changed the page of FREE MINT and MINT.

I made a free mint and a paid mint, and the same image remained as if it were ID 1 for both mints, the IDs could be different, I didn’t understand anything that happened.

The other 2 NFTs that were already there, not updated, still have the wrong BaseURL.

What a mess, it was simply changing the IPFS for the contract to read in the order of the IDs.

https://opensea.io/collection/criminalsnft

MINT: Criminals
https://apps.api.manifoldxyz.dev/public/instance/data?id=1072285936

FREE MINT: Criminals New Home
https://apps.api.manifoldxyz.dev/public/instance/data?id=1042186480

Where do I need to trade only once to effectively trade across the entire collection? and that you keep the order of the IDs and that each ID appears with your image, thank you.

as you can see IDs 1 and 2 still have the old images.

Screen Shot 2023-04-16 at 1.54.51 AM
Screen Shot 2023-04-16 at 1.54.36 AM
Screen Shot 2023-04-16 at 1.54.22 AM
Screen Shot 2023-04-16 at 1.54.08 AM

IDs 2 and 3 have the correct IPFS but showing the same ID

Ok, the reason token 3 and 4 show the same image is because you had two separate claims.
Token 3 was minted via:

And token 4 was minted via:

You have to create separate IPFS metadata for each mint for them to all be unique, and each metadata set needs to be numbered starting at 1.

Each claim page has it’s own unique metadata numbering starting at zero.

Given what you’re describing, if you want all tokens to be unique across both claims, YOU NEED TWO IPFS FOLDERS.

So, if you want to have a set of unique metadata for:

free-mint-holders, you need an IPFS folder with files 1-N and perform the following transaction:
https://etherscan.io/address/0x7581871e1c11f85ec7f02382632b8574fad11b22#writeContract
updateTokenURIParams

creatorContractAddress
 - 0xbc2447c437a9882c73d3178fa3945744693705af
claimIndex
- 1042186480
storageProtocol 
- 3
identitcal
- false
location 
- <YOUR IPFS LOCATION, likely in the form ipfs/<HASH>

This will cause all tokens minted on that claim to be assigned metadata:
ipfs:///1…n

criminals, you need an IPFS folder with files 1-1000 (seems like it is 1000 max supply) and perform the following transaction:
https://etherscan.io/address/0x7581871e1c11f85ec7f02382632b8574fad11b22#writeContract
updateTokenURIParams

creatorContractAddress
 - 0xbc2447c437a9882c73d3178fa3945744693705af
claimIndex
- 1072285936
storageProtocol 
- 3
identitcal
- false
location 
- <YOUR OTHER IPFS LOCATION, likely in the form ipfs/<HASH>

This will cause all tokens minted on that claim to be assigned metadata:
ipfs:///1…n

Given what it seems like you’re trying to do (I can only guess), my recommendation is to let the mint complete first, randomly assign your NFT’s between the two claims, create the two IPFS folders based on that assignment (both need to have files starting as 1 and have non-overlapping metadata) then update both claim pages.

Again, metadata ordering is PER CLAIM PAGE, not globally.

Thanks, now it all makes sense.

Greetings. I am trying the same exact steps that have been mentioned above. I grabbed the address from the extension of my claim page. Once I was in the “12. updateClaim”, everything that was mentioned lined up. The only thing though is the final step that shows on mine is that the system is asking for an erc20 address? I am confused on if I am using the wrong address to be adjusting for said ipfs update, or if the erc20 address is posted somewhere in the contract and I am missing that entirely.

Please follow these updated instructions:

I appreciate the fast reply. So is there a reason as to why my extension contract is showing the erc20? The claim is still active. Does it need to be finished and then maybe the erc20 will disappear? Will run what you provided whats the claim ends as well. Just got very confused as to why mine was showing the erc20 situation.

erc20 defaults to 0x0. You shouldn’t need to enter any of that if you’re using the correct update function (do NOT use updateClaim)

Ohhh, that changes everything. Thank you so much! I was clearly down the wrong path.