Passing provenance hash into nft contract constructor

So I've been reading up a lot about provenance records while working on my own ERC721 collection, and I've learned about what a lot of contracts do wrong with it (such as BAYC for example). My question is:

Is there any reason not to have the provenance record get set in the constructor for the contract? I'll be generating all my metadata and images before deploying the contract anyway. This way it's very clearly
that once set, the metadata can't be manipulated without the provenance hash being disturbed.

I'm asking because I haven't seen anyone really do this in their contract, and this seems like the best solution to me but I'm worried I'm missing something.

Hi there. Same question here. I can't find any example of a project revealing the INITIAL SECUENCE provenance hash.

What am i missing? As i see it there are two options

1) Pass initial hash on the constructor. The problem with this approach is you can't deploy the contract until you have the collection order set.

2) Set the initial hash on a transaction. This way you can deploy and the record will be on-chain for anyone who wants to check.

After a review on some popular contracts, i found this:

BAYC (look for these transactions on Etherscan)

Provenance hash set on 0xf321a2bd4b64e14f2624c2f2a6c916920ff0ffcfbbb6d4e3d459f09cf7b77248	--> Matches the hash on the official website

I reviewed all transactions from Contract deployer (the only address allowed to set this value)	and no other provenenance hash is set. 

When / where they shown the community the initial order?

World of Woman

They DO set two different provenance hash. 

Jul-27-2021 04:19:26 PM +UTC -> Provenance Hash set on transaction 0x9399aa3902a124e33eb64f137fff3c861c26a465f76fec71049d690c4079d1f2

Jul-28-2021 01:37:29 PM +UTC -> Provenance Hash set on transaction 953660c54be933687cc78c804b519f946fac3133ac43f54f6f4c3c5f085be767 --> Matches the hash on the official website

This would makes total sense, they first set the initial hash to prove the initial order, then the finalized one. 

The problem here is i tried to recreate the inital hash and got a different reusults.

These was my steps:

Copy all hashes from website . Concatenated all using the value on second column (Token ID, which represents the initial order ID), then hashed all using this new order.

Resulting hash IS NOT 0x9399aa3902a124e33eb64f137fff3c861c26a465f76fec71049d690c4079d1f2

Lazy Lions

I see the finalized hash set on the Contract, but no record of initial hash. They don't have a provenance section on the website yet.

On this project i found they shown the "team" section on their webiste using the characters they own now. I mean, founder was shown on the website with the character #0 of the current collection BEFORE MINT WAS OPEN. This means the initial order for character 0 was the same as now (for 0 and the rest of the team i assume). So They have a provenance hash but with no altered order.

I also searched on the discord history of these projects looking for the initial secuence with no results

I don't think these projects are doing anything wrong, i guess im missing something here.

Anyone ?

Hey I appreciate the response! Just wanted to throw this out there: I would not use BAYC as an example use of provenance because they did it completely wrong, AND oddly enough a few days ago I tried to calculate their provenance hash to confirm it and it's COMPLETELY wrong, which is pretty sketchy. Unfortunately, the project is nothing but hype and no one at all seems to care.

What do you mean provenance hash is wrong? It is correct, i already check that. Provenance hash matches the current IDs order

You're telling me you hashed every image asset of the collection, concatenated it, and hashed it again and it matched? Because I can assure you that it's wrong, as I have calculated it. I tweeted about it last week and unfortunately have not been able to get any responses:

Go to the BAYC provenance page and search the hash 5bb1c8a8390c284e9a4634c04eee34dfd08759d66d2b613b0631ab10e2f1f3d9. It shows up 31 times in their provenance hash, so I'm saying that their provenance hash was never even correct to begin with.

So I re-read what you posted about BAYC and it's good to know that they've never changed the provenance hash after setting it, which is something I never bothered to check. But still, it seems fundamentally wrong that they even have a function to allow this. And I second your question of "When / where they shown the community the initial order?" I suspect that at the time, literally no one cared. People just were buying into hype

Hi @brodan. I'm not super familiar with NFT-specific terminology. Can you explain what is the provenance hash? Can you share some of the links to things you've read about provenance records?

If I understand correctly it seems the provenance hash is a "commit" as in a commit-reveal scheme. Where you commit to a set of images and their order before minting starts, and at some point later the images and their order are revealed, and anyone can verify that it matches the initial commit, i.e. the minting sequence was not manipulated.

If this is what you mean, then I'd agree with you that setting it in an immutable way sounds like a much better way than having it mutable. But this does not necessarily need to happen in the constructor. You can just have a setter that ensures it's only set once.

Possible reasons to do it after deployment, in a setter, is simply to decouple those two steps given that deployment can be quite stressful and expensive, and you would want to do it well before minting starts, and you wouldn't want to have to throw away a deployment if you need to regenerate the commit for some reason.