Implementations

Implementations

In our NPM package (EVM-contracts (opens in a new tab)), we provide a variety of implementations for each of the modules. They come in 3 levels of increasing complexity:

Ready to use implementations are opinionated and include:

  • Everything from Base Implementation
  • mint, nestMint and tokenURI implementation, varying depending on the implementation.
  1. Premint: Opinionated implementation which includes:
    • mint and nestMint (if Nestable included) implementation, which only the owner or contributor can call.
    • tokenURI implementation, set on via parameter on mint for each NFT.
  2. Lazy Mint Native Token: Opinionated implementation which includes:
    • mint and nestMint (if Nestable included) implementation, where anyone can batch mint tokens by paying the price in native token. Price is set on creation.
    • tokenURI implementation, via baseURI defined on creation. The tokenId is appended to the baseURI.
  3. Lazy Mint ERC20:
    • mint and nestMint (if Nestable included) implementation, where anyone can batch mint tokens by paying the price in ERC20 token. Price and ERC20 token are set on creation.
    • tokenURI implementation, via baseURI defined on creation. The tokenId is appended to the baseURI.
  4. Premint Soulbound:
    • Everything from Premint
    • Uses soulbound implementation, making all tokens soulbound by default.
  5. Lazy Mint Native Token Soulbound:
    • Everything from Lazy Mint Native Token
    • Uses soulbound implementation, making all tokens soulbound by default.
  6. Lazy Mint ERC20 Soulbound:
    • Everything from Lazy Mint ERC20
    • Uses soulbound implementation, making all tokens soulbound by default.

The 3 levels of implementations can be found in this image as follows:

  1. The bottom-most layer is the non-opinionated implementation.
  2. Two layers above are the abstract implementations, together with the different extensions to manage tokenURI.
  3. The top-most layers are the ready to use implementations, available as soulbound or not.

RMRK Package Building Blocks

MultiAsset

The multiasset implementations are available in the @rmrk-team/evm-contracts package (opens in a new tab) at:

Nestable

The Nestable implementations are available in the @rmrk-team/evm-contracts package (opens in a new tab) at:

The Nestable + MultiAsset implementations are available at:

Composable & Equippable

The equippable implementations are available in the @rmrk-team/evm-contracts package (opens in a new tab) at:

Soulbound

We provide implementations for multiple approaches to making a token non-transferable:

  1. Tokens are non-transferable from when they are minted: RMRKSoulbound
  2. Tokens become non-transferable after a specified block: RMRKSoulboundAfterBlockNumber
  3. Tokens become non-transferable after a predefined number of transactions: RMRKSoulboundAfterTransactions
  4. Tokens can be set as non-transferable on a per-token basis: RMRKSoulboundPerToken
ERC20-HolderMetadata