Skip to main content

How to Write a Good NFT Smart Contract

Updated on
Mar 18, 2025
All
Ethereum
NFTs
NFT PhD
Video

21 min read

Overview​

Follow this 73-point checklist to never write a bad NFT smart contract again.

What it is​

This is a set of best practices when writing NFT contracts on Ethereum.

  • A one-stop resource for common best practices implementing NFT contracts.

  • Meant to summarize each item and to make you aware it exists. For the sake of brevity, each item cannot be described in detail here. Please research if anything is unfamiliar.

  • Some points are fleshed out, detailed, and with code examples, while some are included only as one-sentence reminders or as simple yes/no checklist items.

It’s a useful checklist to check your smart contract against.

But if you are still learning and not writing your own smart contracts yet, it's an NFT learning roadmap:

  • Go through the list

  • Can you implement this feature?

  • No? Read about it. Learn how to implement it. Even if you don’t use it, know what it does and why it’s important.

  • Yes? Move on to the next point.

Please keep in mind that it is not a 100%-complete list. It also does not replace the need for security audits.

Note: This guide is based on a series of videos that we have posted on our YouTube channel. All the videos are included in the appropriate sections below. You can choose to read or watch, depending on what you prefer. Video content is the same, but with more explanation and details.

What’s inside​

The 73 points of the checklist are grouped into 8 categories:

  • Preparation (points 1 - 7)

  • Security essentials (8 - 17)

  • Testing (18 - 29)

  • Gas savings (30 - 42)

  • Deployment (43 - 48)

  • Minting (49 - 63)

  • Admin (64 - 70)

  • After launch (71 - 73)

  • Helpful resources

You can go through the list from start to finish. It is grouped into sections that are meant to be chronological, starting with the preparation stage and finishing with the after launch stage. Or you can focus on specific sections, if for example you’re interested only in gas optimization or in the minting stage.

Preparation​

If you prefer to watch rather than read, this guide is split into four videos and covers all of the material in this guide.

This video covers preparation (points 1 - 7), security essentials (8 - 17), and testing (18 - 29).
Subscribe to our YouTube channel for more videos!

1. Pick NFT type​

ERC-721

The current widespread standard.

A few of the ERC-721 NFT projects: CryptoKitties, Crypto Coven, Cool Cats.

A list of ERC-721 Token Contracts on Etherscan.

ERC-1155

  • Batch transfers

  • Supports fungible, semi-fungible and non-fungible tokens

  • Can be reverted in the event of a mistake

Example of ERC-1155 token: adidas Originals NFT

ERC-1155 Token Contracts on Etherscan.

2. Pick the base contract implementation​

3. Pick the chain to deploy to​

More on all the blockchains to deploy to: What Technology To Deploy An NFT | NFT Phd

4. Pick the metadata storage (on-chain vs off-chain)​

More on NFT storage: What Technology To Deploy An NFT | NFT Phd

5. Use the latest Solidity compiler​

Solidity - download the latest version from Solidity website

6. Use modern tools: Hardhat, Foundry​

Hardhat - flexible, extensible, fast Ethereum development environment

Foundry - fast, portable and modular toolkit for Ethereum application development written in Rust

7. Create a Gnosis Safe for proceeds and royalties​

Gnosis Safe - a platform to manage digital assets on Ethereum.

If your project comprises of more than 1 person, an externally owned account (essentially, a wallet) is not a secure way to manage your business’s crypto funds. If an employee goes rogue or is careless with the private key, the funds are gone forever. Even if your business is made up of just yourself, it’s still a poor way to manage funds.

Gnosis Safe solves this. It's a multisig solution, which is essentially a smart contract wallet running on a number of blockchains that requires a minimum number of people to approve a transaction before it can occur (M-of-N).

If for example, you have 3 main stakeholders in your business, you can set up the wallet to require approval from 2 out of 3 (2/3) or all 3 people before the transaction is sent. This assures that no single person could compromise the funds.

Security Essentials​

8. Unencrypted private data​

Nothing on the blockchain is private, including private variables

9. tx.origin​

tx.origin’s only real use case is to check if a smart contract is calling your code. Using it for verification can lead to phishing hacks.

10. encodePacked and hash collisions​

The two values will have the same hash. Use abi.encode instead of abi.encodePacked in this circumstance:

Given that different parameters can return the same value, an attacker could exploit this by modifying the position of elements in a previous function call to effectively bypass authorization. It becomes a problem if it's a part of some important admin function.

11. Calling multiple functions​

Calling multiple functions in a Solidity function has undefined order

Solidity doesn’t specify which function gets called first in this situation:

method1 may be called before method2, or method2 before method1, depending on the Solidity version.

This is highly problematic if they might cause a state change or reference the same location in memory.

Double check the code can tolerate the functions being called in either order.

12. Exact ether balances​

Anybody can change the balance of a smart contract by directly sending ether to it. Even if you override the receive and fallback functions by reverting if msg.value is not zero, another smart contract can selfdestruct and forcibly send ether to another address, bypassing those checks.

If your logic expects a balance of an address to have a precise value or remains static, that assumption can be violated.

See Force Feeding to read more about why relying on exact comparisons to the contract's Ether balance is unreliable.

13. Insecure delegate call​

A delegate call gives the delegated address unlimited power. This should only be used with contracts you control, and it is critical to ensure the address to delegate to cannot be altered by an unauthorized user.

14. Not checking for reverts from untrusted contracts​

This function can experience denial of service if it doesn’t account for the possibility that an external function call can revert.

If you make a call to an external contract, that function may revert. If this is done intentionally, then your contract will not be able to complete its transaction.

15. Security bugs in Solidity compiler versions​

Before committing to using a certain version of the Solidity compiler, check soliditylang.org to see if it has known bugs.

Read through the release announcements: https://blog.soliditylang.org/category/releases/

16. Ensure information sources cannot be manipulated​

The most common manifestation of this vulnerability is flash loan attacks. If your contract checks the price of an asset in a pool, someone can use a flash loan to manipulate that asset price and cause unexpected behavior in your contract.

17. Allowing users to store arbitrary strings​

If your website displays strings stored on a smart contract, and the smart contract allows users to set arbitrary strings (such as giving NFTs nicknames), then they can inject malicious javascript into the website via a <script> tag.

Frontend security is also very important, especially when it comes to user input on websites connected to blockchain and in wallets.

Testing​

18. Use testing tools​

Specific to your blockchain.

Types of tools: formal verification, symbolic execution, linters, and test coverage analyzers.

19. 100% line and branch coverage​

A bug in a smart contract could end the company. 100% coverage is annoying, but it’s a price worth paying.

20. Write unit tests​

Running a unit test requires creating assertions—simple, informal statements specifying requirements for a smart contract.

It then tests each assertion to see if it holds true under execution.

Examples of contract-related assertions include:

  • "Only the admin can pause the contract"

  • "Non-admins cannot mint new tokens"

  • "The contract reverts on errors"

21. Mutation test​

Just because a code is 100% covered doesn’t mean the corner cases are tested.

If you swap a < with a ≤, this should cause your tests to break.

Mutation tests will automatically mutate your code and re-run your tests to inform you how effective your tests are.

22. Formatted code​

Use prettier to maintain consistent code formatting. This makes it easier to read.

23. Static analysis with security tools​

24. Access control makes sense​

This relates to forgetting to put modifiers like onlyOwner on functions. This is what lead to the Parity wallet freeze.

Go through each function, think about what it needs to do and who should be allowed to call it.

25. Inputs properly validated​

What is a sensible minimum or maximum for the input integers? (note that require(x >= 0) is a necessary check)

Are arrays or bytes expected to have a certain length?

26. Check public and private functions​

Make sure public functions do just the minimum required

27. Simulate minting out​

As part of your testing, simulate minting out. What happens when you mint your last NFT? Both on frontend and backend.

Are you able to continue minting? Do you see an error? What kind of information is shown?

28. Measure gas usage​

eth-gas-reporter - gas reporter for Ethereum test suites

Example output:

29. Get your code audited​

Even though the goal of this checklist is for you to write the best possible NFT smart contract, it doesn't mean that by following it you will no longer need to get your code audited. You still need to get it audited. But you may end up paying less because your code structure and quality would be much better.

Gas savings​

This video covers gas savings and optimization (30 - 42)
Subscribe to our YouTube channel for more videos!

30. ERC721A​

  • Compared to ERC721, ERC721A makes minting much cheaper if you are minting multiple tokens.

  • When a user mints multiple tokens, ERC721A updates the balance of the minter only once, and also sets the owner of that batch of tokens as a whole instead of per token.

  • The problem with ERC721A is that because of this minting optimization, users will incur more gas costs when they want to transfer tokens

  • In average transferring, tokens with ERC721A is 55% more expensive.

  • To decide if you are going to use ERC721A, take into account this extra cost for transferring tokens and think if users will be minting big batches of tokens or not

Contracts using ERC721A: Azuki (contract code), goblintown (contract code), Moonbirds (contract code)

31. Don't use Enumerable extension if you don't need it​

Adding more functionality is tempting, for example to make off-chain queries easier

The problem is that any extra functionality you add will increase gas costs.

ERC721Enumerable extension adds a lot of overhead to any transfer (the contract transferring to the user when the user mints, or any transfer from one user to another)

ERC721Enumerable uses 4 mappings and an array to keep track of the token ids each user has. Writing to those structures in each transfer costs a lot of gas.

32. Use mappings instead of arrays​

The advantage of mappings is that you can access any value without having to iterate like you normally do with an array

The disadvantage is that you can’t iterate over a mapping

33. mint vs safeMint​

safeMint is there to prevent someone minting ERC721 to a contract that does not support ERC721 transfer, to prevent the ERC721 token to be stuck there forever. Essentially, it checks if it's sending the tokens to a smart contract or to a wallet.

If you are sure this won't happen (which is almost always the case), you can directly use _mint to save the gas cost.

34. Merkle Tree for allowlists​

Although mapping was cheaper than using an array, it can still be a very expensive solution if you plan to have many (1,000+) users on the allowlist.

Instead of having to write thousands of addresses into your smart contract, you only need to write one hash which is only 32 bytes

This makes writing an allowlist to the smart contract as cheap as possible + it’s independent of the size of the whitelist (the cost will be the same if the allowlist is 10 or 10,000 addresses)

A couple of disadvantages:

  • Using a Merkle tree makes the allowlist mint function more complex which results in a slightly higher cost
  • It’s more work to call the allowlist mint function from the frontend

To check if an address is inside the Merkle tree, you need to provide what’s called a Merkle proof.

35. Use unchecked​

Arithmetic operations can be wrapped in unchecked blocks, that way the compiler won’t include additional opcodes to check for underflow/overflow. This can make your code more cost-efficient.

The savings are not huge but if you have many different arithmetic operations or for example a for loop where you modify the value of the iterator, then you can save some gas for your users with an unchecked block.

36. Use proper optimizer settings​

Solidity compiler comes with an integrated optimizer.

The optimizer is able to reduce gas costs for both deployment and function calls.

To use the optimizer you need to enable it and set the ‘number of runs’.

The way it works is that it makes some sacrifices that can increase the size of the resulting bytecode, which would increase the cost of deploying the smart contract

It’s always better to set the optimizer on. Setting the optimizer off makes gas costs higher both for deploying and calling functions.

The cost of deployment is much higher when the optimizer is off, almost double.

Test different ‘number of runs’ setting. The default is 200 but test it at 1, 200, 1000, 5000, up to a million, if needed (which is what Uniswap used for their contract).

Only lower the optimizer if the contract is too large to deploy.

37. Don’t use anything other than uint256​

In Solidity, variable packing is placing small storage variables next to each other so they sit in a single 256-bit slot.

Variable packing can save cost on deployment if you don’t need the full 256 bits.

Although you might be able to save gas on deployment by variable packing, the users will have to pay extra. Whenever a uint smaller than 256 (or even a bool) is pulled from storage, the EVM casts it to a uint256. This extra casting costs gas, so it’s best to avoid it.

38. Don’t use public if external will do​

external doesn’t allow the contract itself to call the function, but public does. Although they accomplish the same thing (allowing outside calls), external is more gas efficient since Solidity doesn’t have to allow for two entry points.

39. Unbounded loops​

Looping over an array that users can push an arbitrary amount of entries to can result in a function that can no longer be executed when the gas requirement is bigger than the block limit.

40. Unnecessary re-entrancy protection​

Using OpenZeppelin’s non-reentrant modifier on functions that don’t transfer ether or make external calls is a waste of gas.

41. Read and write storage once​

Don’t read from the same storage variable twice in one transaction. Cache it in a local variable.

The exception to this is if you are doing bookkeeping while dealing with untrusted contracts.

42. Avoid reading and writing as much as you can​

Writing to blockchain and reading from it is by far the most expensive activity in terms of gas cost. Avoid whenever possible.

  • Minimize on-chain data
  • Compute known value off-chain
  • Use events. Data that does not need to be accessed on-chain can be stored in events to save gas.
  • Avoid manipulating storage data. Performing operations on memory or call data, which is similar to memory is always cheaper than storage.

Deployment​

This video covers the deployment (43 - 48) and minting (49 - 63) stages.
Subscribe to our YouTube channel for more videos!

43. Sensible deployment strategy in place​

Many deployment tools require private keys to be loaded unencrypted onto the hard drive.

If this must be done, steps must be taken to isolate the computer or to transfer ownership of the contract right after deployment.

Flattening and deploying with a hardware wallet is a good strategy too.

44. Deploy contract from a burner wallet​

Multiple reasons for this: security, privacy, same wallet address on multiple chains, and vanity address.

Security: If you only use the wallet to perform one action (contract deployment), you minimize the risk of getting the wallet compromised. Especially if you use a hardware wallet.

Privacy: You might not want to have the deployed contract associated with you, either for privacy reasons or for keeping the contract secret before the minting starts.

Same wallet address (on EMV-compatible L2s): The contract address is deterministic: it's a hash of your wallet address and account nonce (i.e. number of transactions your wallet has published). This means that if your wallet's first transaction is deploying a contract, it will get the same address on all L2s you deploy it to.

Vanity address: Using the same idea as above, you can use some software that will generate millions of Ethereum addresses to find the one that combined with nonce 0 would produce a nice-looking contract address. This might not be recommended though if the tool is publicly available because someone could use the same tool to generate private keys to your vanity address and compromise it.

45. Wait for cheap gas price​

https://etherscan.io/chart/gasprice - historical gas price chart

https://etherscan.io/gastracker - current gas prices


46. Check NFT projects calendar​

Check upcoming NFT projects to make sure no in-demand project are minting around the launch date:

https://nftcalendar.io/

47. Verify contract on Etherscan​

Install hardhat-etherscan plugin

48. Deploy your NFT to testnet​

  • Test on an actual marketplace
  • Verify all the scenarios
  • Verify minting out
  • Check if everything displays and works properly on marketplaces
  • Make sure not to reveal the metadata & rarity info inadvertently.

Minting​

49. Make a separate minting contract​

Minting logic is a common source of errors, and you don't want those hanging around in the token forever.

Keep the token contract as simple as possible.

50. Code readability​

Fixed pragma

  • Don’t do pragma solidity ^0.8.7 when you set the compiler version yourself. This makes it ambiguous to verifiers which version of solidity was used. Only use this pattern for library code where you are not the one to compile it.

  • Do pragma solidity 0.8.7 instead.

No magic numbers

  • Don’t have unexplained constants in code. It’s better to have constant variables that describe the value, for example:

Proper use of readability keywords (hours, days, ether, 1_000_000, etc.)

  • In Solidity, 1 days will automatically convert to 86400 seconds which is much more readable

  • Use 1_000_000 over 1000000 for readability

  • Use the ether keyword when dealing with powers of 10**18 in the context of Ethereum quantity

Missing require messages

  • require statements should have an explanation.

Undescriptive or misleading variable names, function names, or comments

  • Avoid names like mapping3 or data as they are very ambiguous.

  • Ensure that variable names are precise, accurate, and descriptive.

  • Inaccurate or outdated comments should also be flagged.

Unused variables

  • The tools mentioned in the testing section will catch this, but unused variables hinder readability.

51. Store metadata and media files safely​

More on storage options: What Technology To Deploy An NFT | NFT Phd

Don't share the URLs.

Be careful with launching on testnet to not leak the metadata.

52. Optimize storage​

Make sure you only store on blockchain what is necessary. Having many variables to store data is easier when developing a smart contract, but storage is very expensive on blockchain. Storage costs are both on the contract side (you pay for them), but also on the minter side, when unnecessarily storing data affects the gas price of minting.

For more details and specific optimization tactics, see the gas optimization section.

53. Limit supply​

Have a function to limit token supply. If after launching the collection you decide that the initial supply is too large, it will allow you to limit the collection size.

54. Protect against bots​

Limit mints per wallet, at the very least.

55. Prevent NFT sniping​

Problem 1: Revealing your token metadata (allows the snipers to infer the rarity of a token)

  • Reveal the metadata only after the token has been minted

  • Use batched gradual reveals. All on-chain data is bound to be read and exploited. So don’t verify your contract until just before mint begins.

Problem 2: Minting tokens in a deterministic order (allows the snipers to infer the right time to mint the rare token)

  • Randomize the mint order. Ethereum does not have a built-in random number generator so people have been using current block number as the seed and/or combining it with the minter address for additional randomness. Easily fooled by advanced snipers because it’s not true randomness.

You can use an oracle for randomization (e.g., Chainlink), but even then, advanced snipers can get around it by “peeking” NFTs and reverting the transactions if the minted NFT turns out to be not rare.

There is no 100% way to get around the second problem, unfortunately.

One thing you could do is add allowlists but this will only work if the entire NFT collection can be restricted to an allowlisted community.

A contract example to exploit Meebit and to only mint if it's a rare Meebit

56. Add support for gas-less listing on OpenSea​

*(Outdated since Seaport)
*

You used to be able to pre-approve the OpenSea contract so that your NFT holders don’t need to call setApproval

With the introduction of Seaport, this is no longer necessary.

(For an example implementation, check the Crypto Coven contract)

57. Avoid re-entrancy bugs​

To prevent re-entrancy threat:

  • Ensure all state changes happen before calling external contracts.

  • Use function modifiers that prevent re-entrancy, for example ReentrancyGuard by OpenZeppelin.

58. Add a header and comments to your contract source code​

Crypto Coven contract header

Moonbirds NatSpec comments

59. Accept non-ETH payment​

Enable non-ETH withdrawals (example)

A function to enable ERC20 tokens withdrawal

60. Use new Solidity error type​

A convenient and gas-efficient way to explain to users why an operation failed

Until now, you could already use strings to give more information about failures (e.g., revert("Insufficient funds.")), but they are rather expensive, especially when it comes to deploy cost, and it is difficult to use dynamic information in them.

New Solidity error type

61. Handling random numbers​

For truly and verifiably random numbers, use oracles, e.g. Chainlink.

In all the other cases, a simple keccak256 hashing function with some pseudo-random seeds like block.timestamp or msg.sender should be good enough.

62. Handle refunds​

If something goes wrong and you might need to refund buyers in the future, or even if nothing goes wrong and you just want an option to refund individual purchases, you need a function to handle it. You don't want to do it manually, especially at scale.

63. Whitelisting​

Merkle Trees.
Verification functions available in OpenZeppelin contracts.

Admin​

This video covers admin features (64 - 70), after-launch activities (71 - 73), and a section with helpful resources + a learning roadmap for those just starting out with NFT smart contracts.
Subscribe to our YouTube channel for more videos!

64. Configure on-chain royalties​

EIP-2981 is the best the industry has to offer so far, but not super widely supported.

Also, not easy to enforce.

interface IERC2981 {
    /// @notice Called with the sale price to determine how much royalty
    //  is owed and to whom.
    /// @param _tokenId - the NFT asset queried for royalty information
    /// @param _salePrice - the sale price of the NFT asset specified by _tokenId
    /// @return receiver - address of who should be sent the royalty payment
    /// @return royaltyAmount - the royalty payment amount for _salePrice
    function royaltyInfo(
        uint256 _tokenId,
        uint256 _salePrice
    ) external view returns (
        address receiver,
        uint256 royaltyAmount
    );
}
Logs for Simplified Debugging

You can now access Logs for your RPC endpoints, helping you troubleshoot issues more effectively. If you encounter an issue with your RPC calls, simply check the logs in your QuickNode dashboard to identify and resolve problems quickly. Learn more about log history limits on our pricing page.

65. Pull money out​

This point should be obvious, but a good checklist should cover all the points, including the obvious ones: don't forget the function to withdraw funds. If you do, you'll end up with a contract with funds sitting in it and no way to ever pull them out.

66. Pull tokens out​

Include a function that does the same but for any ERC20 token.

There are plenty of ways your contract can get these, and it would be unfortunate to lose thousands of dollars by not implementing this simple function.

67. Make tokenURI upgradable​

For some projects (on-chain or on-chain wannabes) it's useful to have a way to update tokenURI function in case bugs are found in the future. It's relatively easy to do by delegating implementation to a different contract

If you later want to upgrade how your NFT looks or switch between on-chain and off-chain rendering, you should make your metadata contract swappable.

Contracts using this: OKPC (Contract), Watchfaces (Contract)

Upgradable tokenURI function

68. Reduce supply​

Add a function to reduce supply of your tokens. For example, if you have decided on 10,000 NFTs but after the minting started you want to reconsider and reduce supply to 5,000 or any other number, you would be able to do it with a supply reducing function. Without it, you're stuck with the initial number.

69. Efficient pause implementation​

Hope for the best but plan for the worst. If something goes wrong during the minting stage, having a way to pause a contract might save the project. 

70. Emit events when important things change​

Set up the event at the top of your contract, emit when important things happen.

After launch​

71. Split profits with the team​

If you have followed the preparation phase, you would already have a profit-splitting plan, and a multisig wallet implemented to carry it out. If not, now is the time to do it.

72. Make a long-term ownership plan​

Profits come not only from the minting phase but also from royalties, potential secondary collections, etc. Having a team with skin in the game ensures long-term success. This may have already been done during the preparation stage, same as the point above, but if not, do it right after minting, when maximum hype has already died down, and now it's all about consistent execution.

73. Configure your collection on OpenSea, LooksRare and others​

OpenSea, LooksRare, X2Y2, and tens of other marketplaces, on many different blockchains. Make sure to configure your collection wherever the potential buyers might be at. You want to make sure that it has a good main picture, main banner, and description. Make sure that all the metadata is picked up properly by the marketplace and that it shows all the info for individual items, too. Make your collection and all your items look good everywhere.

Helpful resources​

Contract reader​

https://www.contractreader.io/

Example of a contract in a contract reader: WatchfacesWorld contract.

  • Useful when analyzing contracts

  • Easy to share with others

  • Better than Etherscan

WatchfacesWorld contract loaded in ContractReader

Good NFT smart contract examples​

Study the OGs (but don’t copy them)

Cool smart contracts - a GitHub repository with smart contracts to review and learn from.

Rule of thumb: newer ones are usually better, older are easier to read and learn from.

Smart contract development guides​

There's a treasure trove of smart contract development guides at QuickNode.

Learn how to develop smart contracts through simple tutorials. From writing the code — to deployment and testing of smart contracts — QuickNode has got you covered.

A few helpful guides:

Starting out? All the best resources to learn from​

1. Read Solidity docs

2. Read a lot of code

  • Almost all smart contract code is published on Etherscan, the best ways to learn is to look at how other project coded their projects and learn from them.

  • Another good resource is looking at open source solidity projects on GitHub

3. Solidity & NFT tutorials

Patrick’s 32-hour Solidity course ← a MUST!

OpenSea ERC721 guide - simple tutorial for a customizable marketplace for buying and selling on OpenSea

CryptoZombies - it was the first tutorial on the internet for NFTs, and it keeps getting better, with up-to-date info. Learn by building a zombie game.

4. Solidity Patterns

  • A collection of design and programming patterns for Solidity.

  • Each pattern consists of a code sample and a detailed explanation, including background, implications and additional information about the patterns.

  • For Solidity version 0.4.20. Note that newer versions might have changed some of the functionalities.

5. Start your own projects

  • Nothing beats practical experience

  • Start your own NFT projects or with an artist to create something together

  • You gain experience by doing so keep coming up with new ideas and experimenting, or even try re-creating a project.

NFT API​

When you have your smart contract ready and rocking, you need a frontend for it, to present your NFTs in the best (and easiest) fashion.

Retrieving NFT metadata from the blockchain is tedious and time-consuming. QuickNode NFT API does the heavy lifting for you across Ethereum and Solana NFTs, making the data you need searchable and accessible.

More advanced?​

Focus on security.

Security games:

Don’t forget​

  • To have fun
  • You can do it
  • You’re awesome

Summary​

How to write a good NFT smart contract?

  • Start with preparation stage (so that to avoid mistakes later)

  • Focus on security first and foremost

  • Whatever you do - test! A small price to pay for peace of mind

  • It all costs money, so remember to save gas. For yourself and for everyone buying and trading.

  • Don’t burn yourself at deployment stage

  • Most important stage for users: minting. Don’t disappoint them

  • Think about the future with change-conscious admin features

  • Think in advance about what happens after launch

  • Don’t forget to have fun

Awesome work! You have learned how to write a good NFT smart contract and successfully deploy it to a blockchain. To learn more, check out some of our other smart contract writing tutorials here.

Sources​

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.

Written by

Radek Sienkiewicz

Last updated on
Share this guide