Comment on page

Quickstart

A quick-start guide to using RMRK legos.

The easiest and most convenient way to start developing your NFT 2.0 project using RMRK legos is by using RMRK wizard. The RMRK Wizard is the application for building your NFT 2.0 smart contract templates.
RMRK EVM Wizard
RMRK EVM Wizard
You can refer to the Arcane edition of Developer notes for a lengthier introduction to RMRK Wizard
​​
​​
Use RMRK Wizard to configure your smart contract
The Wizard offers a variety of options to tailor the generated smart contract to your project's needs:
Option
Description
Notes
Name
Name of the token collection.
The longer it is, the higher the deployment cost will be due to the cost of storing a string variable.
Symbol
Symbol of the token collection.
/
Ready to Use
Determines whether the smart contract needs any additional customization or can be deployed and used immediately.
/
Minimal Implementation
Determines whether the smart contract has basic function implemented for you or if you want to implement them yourself.
If you decide to implement the basic functions yourself, you can refer to the TODOs generated by the wizard to implement the necessary code.
Lego
Determines which RMRK lego to use.
We strongly suggest using the Equippable lego if your custom business logic fits within the smart contract size limit.
Mint Method
Determines the way the tokens are minted.
Each minting method is limited to itself, but you can customize it to support additional ways of minting.
Soulbound
Determines whether the tokens can be transferred by their owners or not.
Conditional transferability can be achieved by overriding isTransferable function.
Token URI
Determines how to select the metadata URI to serve as the token URI.
/
Auto-Accept Children
Determines whether the child tokens are automatically accepted.
In the event that the parent token is owned by the child token being nested, this will automatically accept the child token.
Lock Supply
Determines whether the maximum supply of the token should be modifiable to current supply.
Even if the maximum supply exceeds the total supply, this method allows you to change the maximum supply of tokens to the current supply and disable minting.
We strongly suggest using the Equippable RMRK lego to ensure forward compatibility with whatever utility your tokens evolve into. Using any other lego should only be done if your business logic causes your smart contracts to become too big to deploy, but even then, you should examine your smart contract architecture to extract some of the business logic to another smart contract.
When using ERC-20 tokens to interact with your smart contract, the approval to interact with the tokens needs to be granted to your smart contract. Without the approval, users won’t be able to mint their NFTs using ERC-20 tokens.
Using the Soulbound option makes all tokens non-transferable. Without additional custom logic, owners will never be able to transfer them.
Deploying your smart contract
Once you have configured your smart contract, you can deploy it. You can open the smart contract directly in Remix IDE, or you can import it into your Hardhat or Foundry project.
The following section examines the use of Remix IDE and Hardhat framework:
Remix IDE
Hardhat
1.When you are happy with the selected options, you only need to click on the Open in Remix button:
Open in Remix
This action should open the Remix IDE for you with the configured smart contract already opened and ready to be compiled.
2.Once compiled, you can go to the Deploy & Run Transactions tab:
Deploy & Run Transactions tab
3.To connect your wallet to the IDE, you need to select the Injected Provider - MetaMask environment option:
Environment selection
Make sure the wallet is set to connect to the network you wish to deploy your collection to.
4.Expand the Deploy parameter input section:
Deploy parameter input section
5.Input the required parameters:
Deploy parameters
Collection Metadata - The metadata URI for the collection. The instructions on how to format it and pin it to IPFS are available in the Metadata section of this page.
Max Supply - The maximum supply of NFTs in this collection.
Royalty Recipient - The recipient of royalties according to ERC-2987.
Royalty Percentage BPs - The percentage of royalties according to ERC-2987 expressed in Basis Points. 1 BP equals one hundredth of a percent, so 100BPs equals 1 %.
Base Token URI - The base token URI to which the token IDs are appended if the Enumerate method of getting the token's URI is used.
Price per Mint - The cost of minting a single token expressed in the lowest denomination of the token used to pay for minting. This is required when lazy minting is used.
ERC20 Token Address - The address of the smart contract of the ERC-20 token used for lazy minting. This is only applicable when Lazy minting with ERC-20 tokens is used.
​
6.You are ready to deploy your collection. Click on the transact button, and your wallet should prompt you to sign the deployment transaction:
transact button to initiate deployment
7.If you wish to interact with your collection without the user interface, you can do so directly in the Remix IDE by expanding the smart contract added below the deploy section: 
Expand the smart contract interface to interact with it
1.Use our GitHub EVM Template to create your project's repository.
2.Clone it to your device and install all of the dependencies using the yarn command.
3.Download the generated smart contract and place it into the contracts/ directory, or create an empty smart contract and copy the generated code into it.
4.Use the Deploy Script section of the RMRK Wizard to generate the deploy script for your smart contract. Fill in the details that the form requires of you.
5.Download the generated script and place it into the scripts/ directory of your project, or create an empty deploy.ts file within the scripts/ directory and copy the contents of the generated script into it.
6.Compile the smart contract using yarn hardhat compile.
7.Validate that the smart contract with your customizations can be deployed to a live network using yarn hardhat size-contracts.
8.Rename the .env.example to .env and replace the values with your own.
9.Deploy the smart contract using yarn hardhat run scripts/deploy.ts --network [NETWORK].
To make sure everything works as expected, we suggest you try deploying your smart contract to a test network before deploying to a main one.
You can refer to the Metadata section to examine the expected metadata structure.
Metadata
The metadata needs to be formatted appropriately based on what it represents. There are four different formats of metadata. Let's examine them:
Collection Metadata
Token Metadata
Asset Metadata
Catalog Metadata
The collection metadata is used to provide information about the collection. While most marketplaces store and access it in a centralized way, Singular expects to be able to retrieve it from a smart contract in a decentralized way.
The following values are expected:
name - The name of the collection.
description - The collection's description.
mediaUri - The URI to the full-sized image representing the collection.
thumbnailUri - The URI to the thumbnail representing the collection in the preview views. The preferred size of the thumbnail is 350x350px
externalUri - The URI leading to the website of the collection.
Sample metadata looks like this:
{
    "name": "Collection name",
    "description": "The full description of the collection.",
    "mediaUri": "ipfs://fullSizeMediaUri",
    "thumbnailUri": "ipfs://thumbnailUri",
    "externalUri": "https://project.com"
}
The token metadata should represent the individual token. It usually contains the token's thumbnail to be presented in the token's preview, the full-sized token's media, the token's attributes, and additional metadata.
The suggested metadata contains some legacy keys as well as the current ones in order to comply with both the legacy marketplaces as well as the next-generation ones.
The following values are expected:
name - The name of the individual token.
description - The individual token's description.
externalUri - The URI of the token's project website.
external_uri - The legacy formatting of the URI of the token's project website.
mediaUri - URI to the token's media file.
image - URI of the image representing the token. This is a legacy key with a function equal to that of mediaUri
thumbnailUri -  URI to the token's thumbnail that is used as a token's preview.
thumbnail_uri - The legacy formatting of thumbnailUri containing the URI of the token's thumbnail.
preferThumb - A flag signaling to the marketplace to prefer presenting the thumbnail instead of media associated with mediaUri.
license - Name of the license applied to the token.
licenseUri - URI to the token's license.
attributes - An array of token's attributes where each item represents one attribute:
label - The name of the attribute.
trait_type - The legacy formatting of label value representing the name of the attribute.
type - The type of the attribute. The possible values are:
number
float
integer
string
date
percentage
value - The value of the attribute.
Sample metadata looks like this:
{
    "name": "Token name",
    "description": "Token description",
    "externalUri": "https://project.com",
    "external_uri": "https://project.com",
    "mediaUri": "ipfs://tokenMediaFile",
    "image": "ipfs://tokenMediaFile",
    "thumbnailUri": "ipfs://tokenThumbnai",
    "thumbnail_uri": "ipfs://tokenThumbnail",
    "preferThumb": true,
    "license": "License title",
    "licenseUri": "https://license.com",
    "attributes": [
        {
            "label": "Attribute name",
            "trait_type": "Attribute name",
            "type": "number",
            "value": 42
        },
        {
            "label": "Second attribute name",
            "trait_type": "Second attribute name",
            "type": "string",
            "value": "Example attribute"
        }
    ]
}
The asset metadata should represent the individual asset. It usually contains the asset's thumbnail to be presented in the asset's preview, the full-sized asset's media, the asset's attributes, and additional metadata.
The suggested metadata contains some legacy keys as well as the current ones in order to comply with both the legacy marketplaces as well as the next-generation ones.
The following values are expected:
name - The name of the individual asset.
description - The individual asset's description.
externalUri - The URI of the asset's project website.
external_uri - The legacy formatting of the URI of the asset's project website.
mediaUri - URI to the asset's media file.
image - URI of the image representing the asset. This is a legacy key with a function equal to that of mediaUri
thumbnailUri -  URI to the asset's thumbnail that is used as a asset's preview.
thumbnail_uri - The legacy formatting of thumbnailUri containing the URI of the asset's thumbnail.
preferThumb - A flag signaling to the marketplace to prefer presenting the thumbnail instead of media associated with mediaUri.
license - Name of the license applied to the asset.
licenseUri - URI to the asset's license.
attributes - An array of asset's attributes where each item represents one attribute:
label - The name of the attribute.
trait_type - The legacy formatting of label value representing the name of the attribute.
type - The type of the attribute. The possible values are:
number
float
integer
string
date
percentage
value - The value of the attribute.
Sample metadata looks like this:
{
    "name": "Asset name",
    "description": "Asset description",
    "externalUri": "https://project.com",
    "external_uri": "https://project.com",
    "mediaUri": "ipfs://assetMediaFile",
    "image": "ipfs://assetMediaFile",
    "thumbnailUri": "ipfs://assetThumbnai",
    "thumbnail_uri": "ipfs://assetThumbnail",
    "preferThumb": true,
    "license": "License title",
    "licenseUri": "https://license.com",
    "attributes": [
        {
            "label": "Attribute name",
            "trait_type": "Attribute name",
            "type": "number",
            "value": 42
        },
        {
            "label": "Second attribute name",
            "trait_type": "Second attribute name",
            "type": "string",
            "value": "Example attribute"
        }
    ]
}
The Catalog metadata provides information about the Catalog. In addition to the Catalog, the Slot parts require their own rudimentary metadata as well.
As the catalog itself is incompatible with legacy marketplaces, there is no need for legacy keys in its metadata.
The following values are expected in the Catalog metadata:
name - The name of the Catalog.
description - The Catalog's description.
type - The media type of parts provided in this Catalog.
mediaUri - The URI to the main media representing the Catalog.
thumbnailUri - The URI to the Catalog's thumbnail.
externalUri - The URI to the Catalog's project's website.
Sample Catalog metadata looks like this:
{
    "name": "Name of the Catalog",
    "description": "The Catalog's description",
    "type": "Type of parts provided by the Catalog",
    "mediaUri": "ipfs://mediaFileUri",
    "thumbnailUri": "ipfs://thumbnailFileUri",
    "externalUri": "https://project.com"
}
The Slot Part metadata expects only one value:
name - The name of the Slot Part.
Sample Slot Part metadata looks like this:
{
    "name": "Example Slot part"
}
We strongly urge you to store your metadata in a decentralized way because this encourages trust and provides metadata access without downtime.

Option	Description	Notes
Name	Name of the token collection.	The longer it is, the higher the deployment cost will be due to the cost of storing a string variable.
Symbol	Symbol of the token collection.	/
Ready to Use	Determines whether the smart contract needs any additional customization or can be deployed and used immediately.	/
Minimal Implementation	Determines whether the smart contract has basic function implemented for you or if you want to implement them yourself.	If you decide to implement the basic functions yourself, you can refer to the TODOs generated by the wizard to implement the necessary code.
Lego	Determines which RMRK lego to use.	We strongly suggest using the Equippable lego if your custom business logic fits within the smart contract size limit.
Mint Method	Determines the way the tokens are minted.	Each minting method is limited to itself, but you can customize it to support additional ways of minting.
Soulbound	Determines whether the tokens can be transferred by their owners or not.	Conditional transferability can be achieved by overriding `isTransferable` function.
Token URI	Determines how to select the metadata URI to serve as the token URI.	/
Auto-Accept Children	Determines whether the child tokens are automatically accepted.	In the event that the parent token is owned by the child token being nested, this will automatically accept the child token.
Lock Supply	Determines whether the maximum supply of the token should be modifiable to current supply.	Even if the maximum supply exceeds the total supply, this method allows you to change the maximum supply of tokens to the current supply and disable minting.

Getting started - Previous

Getting started

Next - Getting started

Which lego to use?

Last modified 2mo ago