This is in response to a query from my contractee. Everything I have done is in GitHub in two public repositories--1. the "server side" contracts themselves and code for metadata management, and 2. the end-user web "button" code (MetaMask, etc.). Regarding dynamic NFTs, the code already allows dynamism to a degree. In NFT.sol, the function "setBaseTokenURI(string memory _baseTokenURI)" (line 14) allows all of the metadata to be changed by pointing to a new base (directory), where the files are 1, 2, 3, .... Those files contain the short JSON metadata file which in turn point to the actual images. I have tested the function rather extensively. It works.
Everything I have done assumes one has read through OpenSea's tutorials through "part 4" as linked below.
It doesn't appear I linked to "mint dev" from this page before. That is my latest web code.
For the (public) record, the project launch date is predicted to be in August, so my part has been more or less on pause for weeks.
My client will use OpenSea as a secondary market. The secondary market has nothing to do with me as the contract writer; at least, that is my conclusion so far. However, I didn't understand that weeks ago, so I used one of OpenSea's tutorials. What I mainly wound up using was their "part 4" code. I'll mention this other OpenSea doc link, but I haven't looked hard at it yet.
OpenSea's examples were quite good. The only major criticism I have is that the test ETH faucet they recommended (for the Rinkeby Testnet) did not work and wasted my time trying to get it to work. The one they sent me to forced one to post publicly on social media. The ones that worked did not. In hindsight, a hint that it wasn't working was that the previous transactions displayed were from "2 days ago."
RinkebyFaucet works without an account to receive 0.1 ETH per day or 0.5 with an Alchemy account. You'll probably want an Alchemy account anyhow, as recommended in OpeaSea's tutorial. It took 1.5 or 2 minutes to process without an account, or without being logged in.
I originally used "MyCrypto" in March. It's not working now. I mention it only because it did get me started.
Contract creation cost 0.0034 ETH with a creation time of several minutes, so that first 0.01 limit from MyCrypto was a problem. See my test account history on EtherScan. Note that it includes my test contracts.
I noted that an EtherScan key takes 5 - 10 minutes after creation to become valid.
npx hardhat run scripts/deploy.js --network rinkeby --verbose
# part 1 version, I think
npx hardhat deploy
# part 4 version
npx hardhat mint --address 0x9BEb87E50Dbb3f1356C9B8d72A5F08C794d3b95f
npx hardhat deploy --network rinkeby
Contract deployed to address: 0x51174F5CD092e8876846684607eB8f89A8C93def
# That is the address of the contract itself. You can see from EtherScan, created Mar-10-2022 10:17:04 PM +UTC
npx hardhat verify 0x8ca86d22241C3458441E286Fa0062023988c1E61
# this is the 2,222 limit 0.08 ETH second contract
First, note that if the code is verified as noted in the tutorial and with the command above, you can mint on EtherScan from the contract, such as my first 4/23/2022 contract. Put 0.08 as the payable amount. The connected address / "msg.sender" will receive the token.
If you do it that way, you can see (or at least copy and paste) the "data" param in MetaMask. That data param is the ABI / application binary interface. It's the "mintToMsgSender()" function's signature in Ethereum Virtual Machine (EVM) bytecode / binary code. You need that param in the client-side (web) JavaScript, as shown in my example.
I initially assumed that the ABI / "data" param was a compile time signature of the function name and parameter types. I spent an enormous amount of time until I realized it's a runtime signature including the actual value of the parameters for that transaction. As of the start of my workday on 4/23/2022, I am still using the Etherscan verification and MetaMask to get the proper "data" value. The general solution is documented in the JavaScript / Node.js Web3 docs .