etherscan | A thin , lightweight promise wrapper for the api | REST library

BscScan and EtherScan use the Transfer() event to update their statistics of token holders and to display amount of tokens transfered in the transaction detail page.

If you don't emit the event, it

• wouldn't display the "Tokens Transferred" field in the transaction detail page
• wouldn't update the token balance of the sender and receiver on Etherscan (e.g. on their address detail page)

But the contract would still transfer the tokens, and Etherscan would still show the transaction detail page (just without the tokens data).

Your mintNFT() function doesn't emit any event containing the newItemId.

solidity is using the standard definition of transfer

There's no "standard definition", the ERC-721 standard only defines an interface and few other rules - and the actual implementation (of the interface) is on each developer. However I'm assuming that by the "standard definition" you mean the OpenZeppelin implementation, which is a widely used implementation of the ERC-721 standard and is used by many people who start coding in Solidity.

You can see in the linked implementation, that the OZ _mint() function emits the Transfer() event, where the 3rd argument is the minted token ID.

So executing your mintNFT() function effectively emits the Transfer() event that contains the newly minted token ID as a value of the 3rd parameter.

After you've executed the mintNFT() contract function from your JS code, it returns a PromiEvent object, that you can use to catch its receipt event.

The receipt contains the emited logs, where you can find the Transfer() log as well.

Simply put I had to go down a rabbit hole to work this out as I'm pretty new to Solidity.

I had to do the following;

1. Learn and use https://www.trufflesuite.com/ to setup a project and put my contract there (Using Ganache helped a lot with testing for anyone new to Solidity too)
2. Use HD Wallet provider package and follow tutorial here to get it on ropsten Etherscan https://medium.com/coinmonks/5-minute-guide-to-deploying-smart-contracts-with-truffle-and-ropsten-b3e30d5ee1e
3. Finally, use truffle-plugin-verify https://github.com/rkalis/truffle-plugin-verify to verify the contract on Etherscan

All in all, I am pretty sure there is no way within the Etherscan web app to verify a contract that contains an imported file.

The final product is here if anyone is interested in seeing how I structured it all https://github.com/lukecurtis93/viper-nft (it's just a CryptoKitties clone I found online as a base and updated it all)

Goerli Etherscan has a different API host.

You need to use https://api-goerli.etherscan.io/ instead of https://api.etherscan.io/

Source: https://goerli.etherscan.io/apis#accounts

The Remix bytecode export contains the bytecode variable definition and assembly block without the constructor being executed - just the actual definitions compiled to bytecode.

Constructor usually returns the contract instance (including its parent contracts and imported libraries). But in this case, the assembly block forces the EVM to not return the contract instance, but to return the value of the bytecode variable from the constructor.

Then the deployment process continues as usual - the EVM stores the constructor return value (usually the contract instance, now the bytecode) into the contract storage.

i have looked at the html page and you have an iframe for this table and the id of this iframe is tokenpageiframe

The Chainlink VRF has gas limits on callback. Reference the documentation to see exactly how much for each network.

Apparently after verifying on Etherscan, all token contracts become visible to the public.

Their bytecode is already public when they're deployed. You're just making the source code public too.

Isn't that a security risk ?

Only if your contract contains a security flaw.

But if your contract does contain a security flaw, it's a security risk to deploy it even without publishing the source code. There are ways to "decompile" the bytecode to some pseudocode or even Solidity to some extent, so anyone can see the logic of your contract even if the source code is not published.

What if we do not verify our contract ?

It's a fully functional contract, just without verified source code.

Can some of these contracts (that are verified and visible) on the Etherscan be used again for new coins, or are they copyright protected ?

It depends on the license under which the authors created it. It's possible to bypass the license - so if someone publishes the contract under "Do not copy" license, someone is still able to copy... But that's a legal topic, not programming.

OpenZeppelin's Ownable.sol defines the default owner value as the contract deployer. You can later change it by calling transferOwnership() or renounce the owner (i.e. set to 0x0) by calling renounceOwnership().

The onlyOwner modifier reverts the transaction if it's not sent by the current owner. (see the code)

So you need to call the mintNFT() function from the same address that deployed the contract, because that's the current owner. Or you can change the owner first by calling transferOwnership() (from the current owner address).

Removing the onlyOwner modifier from the mintNFT() function would allow anyone to call the function.