Are NFT projects doing starting index randomization and provenance wrong or is it just me?

Smart Contracts
,
41

I've used this simple dumb script to do it and it has always worked so far:

import IPFS from 'ipfs-core'
const { globSource } = IPFS;

(async () => {
  const DATA_PATH = `ipfs/metadata`

  const ipfs = await IPFS.create()

  for await (const result of ipfs.addAll(globSource(DATA_PATH, {
      recursive: true
    }),
    {
      onlyHash: true,
    }
  )) {
    console.log(`${result.path} - ${result.cid.toString()}`)
  }

  return process.exit()
})()
1 Like
42

From my understanding, startingIndex is used to determine the order of the metadata after the sale is over and it is time to reveal. At the end of the sale, startingIndex is set. Then, metadata is ordered based on the startingIndex, uploaded to IPFS, and then the baseURI is set.

1 Like
43

I'm trying to understand what is a provenance hash, what does it do, and how do you calculate it?

1 Like
44

do you figure out your question yet, i'm curious too on how the reveal works

1 Like
45

this might help you understand it much better than a quick explanation

[The Elegance of the NFT Provenance Hash solution | by Richmond Lee]

1 Like
46

Interesting piece of research published by Paradigm:

Twitter summary here.

47

Thanks @jalil – only-hash works well

49

One of our solutions is to provide incomplete metadata to NFTs buyers. Open the image itself. The complete metadata is loaded after the sale of the collection. We are changing the UID of the metadata. We call a function to freeze the UID.

50

Based on the BAYC contract startingIndex doesn't actually do anything.

51

Many thanks for this, was speaking to a fellow Dev and discussed this elegant solution. The starting index works great here as it's dynamically calculated in the tokenURI() method which OpenSea and other marketplaces use to fetch metadata.

53

The only problem I see here is that now it is common (and seemingly desirable) for token metadata to contain a "name" attribute which includes the token ID.
For example, "Daturian 1234".
So not knowing what metadata a token would be assigned would take out the number from that name attribute. Not that big of a tradeoff in my opinion, but people tend to really want to keep that number in there so it is apparent how early they minted. Maybe I'm misunderstanding and there is a way to keep the number?

54

You can keep the number if you generate the metadata JSON on chain.

55

In case of BAYC.

Token ID #0 is the owner of Image #8853 (see BAYC provenance page):

8853	  |  	0	  |  	e45a1f6f4ce083f0718409066b9dce1c7003c72c514e8552cf33515ac103bcea	  |  	QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQ

Now tokenURI(0) returns the following metadata location:

ipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/0

Which in turn does include Image #8853 !

ipfs://QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQ

So basically they re-ordered the metadata files in a new IPFS folder after the sale. Which is fine because they have published the initial sequence of Images.

# This happened after the sale ended.
# This a new IPFS folder will all metadata files re-ordered according to `startingIndex`.

setBaseURI('ipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/')