Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Boots is a proprietary NFT upgrade service that exists on top of the Raindrops Protocol that allows NFT holders to trade and collect traits on their NFT in a controlled and fee-gated environment that produces reliable new revenue streams for NFT companies and the platform and is consistent with web3 principles.
The only way to customize an NFT presently is to trade it for another. The best NFT collections are the ones with enough trait variance that a given user can find a PFP that matches about 80% of their personality. Inevitably, the quest for a "forever PFP" is out of reach for most and more importantly, doesn't lead to much money exchanging hands.
In the traditional secondary sales model, volume and therefore income to NFT companies decreases over time as collectors settle in for the long haul. There is little incentive to trade on existing traits, and speculators lose interest in collections that are no longer new.
Releasing new sub-collections to revitalize revenue is a short-term salve. The long-term effect is that your brand is now diluted across many different collections, all which share the same-sized user base and compete for volume. You may have won a short-term cash prize but in the long term you now have more collections to maintain and a wider roadmap to service.
Royalties on Solana are unenforceable because the Token Program has no idea what they are, and doesn't care what they say when a user initiates a token transfer. There are no plans by the Solana team to merge the Token Metadata program into the Token Program at any point in the future to rectify this. The only real solution to this is to either turn the Token Metadata program into a clone of the Token Program, which is infeasible, or enforce royalties punitively, which does not have 100% efficacy.
All NFTs come with some traits that are customizable and some that are inherent traits, as defined by the Raindrops protocol. Think what shirt an NFT is wearing vs its skin color. The shirt is a token that the NFT is carrying in its backpack and is presently equipped. It's skin-color is a piece of data recorded in an on-chain account similar to Metadata from Metaplex. The token can be unequipped, removed, and like any old semi-fungible token, traded. On removal or addition, the NFT's image is updated to reflect the image change.
Now people can truly customize their NFT, and can get to 100% match without breaking the bank!
With Project Boots, new SFT tokens representing new traits can be dropped by the season or monthly using the Launchpad feature. This can take place through collaborating and splitting revenue/royalties with artists, other major clothing brands, or by releasing your own new traits. There will also be opportunities to use Cupcake technology to couple the clothing to IRL phygital goods.
Fashion brands have used this technique from time immemorial to revitalize their income streams every season and every year. Why trade on last year's trait?
With each new trait collection, the power of expression for your NFT collection grows. Without sub-collections to dilute volume, it remains moving in the base collection, propping up royalties there. Customers will be forced to keep up with each monthly or season installment of traits or their NFT will fall out of cultural relevance. Old traits will trade on a secondary market similar to discount stores found in the real world today.
With the Project Boots system, while our marketplace does enforce royalties when the secondary market is used for trait token sales, this is not intended to be the primary source of revenue. All Boots enabled collections require the authority on the collection to sign off on any addition, removal, equipping, or un-equipping of any trait on the collection. What this means is that the NFT Collection Owners are the gatekeepers of change.
When a user wishes to apply a new trait in their NFT's backpack, they could attempt to sign a transaction that tells the Raindrops protocol to do this, but it would fail because they lack permissions on Boots NFTs. They instead must cosign a transaction with the NFT Collection Owner. The Boots system will provide such a cosigned transaction, but this transaction will come with a standard SOL fee as a side-instruction - which will be split 20% with the platform and 80% among the royalty recipients on the NFT Collections.
This new revenue source is guaranteed by the protocol, cannot be bypassed, and while smaller in magnitude than a secondary sale, is going to happen significantly more frequently. Web2 has already proven the magnitude and power of micro-transactions. This is the future of the NFT ecosystem and the future of your company.
Welcome to Boots.
Boot-up is a command line interface for making a collection work with the Boots service. If you have a NFT collection currently on-chain, the steps in this guide will "boot up" that collection.
The boot-up command line interface is used to prime your collection to be used with the Boots protocol.
We will take you through the following steps:
Create Main Class
When you build something, you need a blueprint. We will show you here how to create your blueprint on-chain to allow your project to be booted up.
Create the Items Collection
This step will establish the collection for your items. It establishes this collection of NFTs or SFTs to be able to be equipped on the NFTs of your collection.
Create the Item Classes
Each of the items that you want to equip on your NFTs will need to have its own blueprint. This step creates that for each of your booted items.
Create Players
This last step establishes the NFTs in your collection as Bootsified NFTs.
We will assume that you have an on-chain collection of NFTs, and assume you are familiar with using a command line interface (CLI) to execute commands on your operating system of choice.
This page describes the options you can set as part of the configuration
The scope defines what type or set of NFTs you want to establish with Boots. There are currently three options
If this is set to true, the Boot-Up CLI will scan the NFT to make sure that they weren't given more than one of each trait. This process only applies to NFTs that have reached their final state.
*IMPORTANT NOTE* DO NOT set this to true after the collection is being used by your community. This will prune duplicate tokens from the Player class of the NFT, so TAKE CAUTION HERE.
This serves as a key to save the process of the Boots conversion for your NFTs. This will be constantly updated during Step 4 - Create Players, so the initial value for this key should be set to null.
This is a whitelisted array of the body parts you would like to enable for boots. These parts can be changed in your collection.
This array is the set of attributes that you do not need to be able to change through Boots. These are things like the base body for your character. In addition, users will be able to change these items by equipping them as consumable items, and that these will be stored as items on-chain.
This is an array of configuration sets for other non-graphical statistics that you would like to apply to the player class of this collection. The form is described here: Player - Basic Stats​
if true, these items will be created as Semi-Fungible Tokens (SFTs).
the name of the on-chain class for this collection
reserved for the namespace for this collection. Namespaces are currently a work in progress, so stay connected to @only_raindrops on Twitter for updates.
Set skipUpdates to True if you do not want the player to be updated with any changes that have happened to the NFT's parent class since the last run. For instance, if a new layer is desired, or if you want a new statistic applied to this player definition, you would want to keep this set to false.
Setting this to true means that Boot-Up will retry configuring your NFT for Boots if an error happens during the run. If you set this to false, the error will propagate up and the next NFT will be tried. It is recommended to keep this set to true.
Set this to true to allow a holder to be able to equip their NFT in this collection. If false, then the collection owner must be the one to equip the collection NFTs. In addition, fees for equipping items can be circumvented if this is set to true.
This is where you are defining the items that will be able to be equipped on your players.
For each item, you will add a default boilerplate entry.
The layer will be populated by Boot-Up with the configuration, so leave it defined as is.
In addition, this is where the bodyPartLayers comes into play. If you want to enable creating NFTs or SFTs for these items you will need to whitelist them in the bodyPartLayers key.
This is the location of the directory that holds the images for the individual items. When the process runs, it will create the NFT or SFT on chain for you, and this is where you have the image files specified.
NAMING CONVENTION FOR THE IMAGE FILES
Because the system needs to be able to find the files in your file system, you will need to follow a character substitution pattern when you name your image files. In general, use an underscore ( _ ) character to substitute for whitespace, and replace any special characters as follows:
So a layer named
"EXALTED_STAT | RUGGED_COUNT: 2"
would end up with an image file named
"EXALTED_STAT__RUGGED_COUNT_2.png"​
This is the mint id for the collection that you intend to enable with Boots.
This is an optional path to an image file used when creating the collection for items. If this is not set, the first bodyPartLayer trait image file will be used.
This is the mint that will be used to represent the master PlayerClass for Boots. You can place the collectionMint here if you control it and are the UpdateAuthority but if you don't have those things - no worries as they are not required. You can leave it null, and we will make one automatically when the script runs.
Raindrops allows each NFT in principle to have multiple items and players defined on top of it through the use of indexing. Therefore, for each Boots collection, you must label which index you decided to use for the items and the NFTs themselves.
Raindrops allows each NFT in principle to have multiple items and players defined on top of it through the use of indexing. Therefore, for each Boots collection, you must label which index you decided to use for the items and the NFTs themselves.
This is where the CLI will store the class information for the Items class of the collection. This is automatically populated by the application, so just leave it at null
to start. In general, this specifies the abstract top level class of the ItemsCollection. The ItemClasses for the collection inherit their properties from this ItemsCollection, and then each Item inherits properties from its ItemClass. For more information on how Items are composed, have a look at that section of the Raindrops documentation.
This is where the application will store the class information for the collection's main class. This is populated by the application.
This will be the name of the collection NFT for the class. When the application creates the collection NFT for Boots, this is the name it will apply to the Collection NFT.
This is the public key for the Collection NFT of the items for the collection. This is populated by the application.
This step creates the Items collection and stores the information needed in the configuration file.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, the existingCollectionForItems
entry of the configuration file will be updated with the item class definition information.
Once this command finishes successfully, you can move on to the next step.
This step creates the player class on chain and stores the information needed in the configuration file.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, the existingClassDef
entry of the configuration file will be updated with the class definition information.
Once this command finishes successfully, you can move on to the next step
Id | Scope | values example | Description |
---|---|---|---|
character | replace with |
---|---|
option | description |
---|
0
List of NFTs
["GiD1ex1VyEXALniJJvL6KcgQ5mGB4BLzvjM1bQzUXs1T","Cu89qmdY4a6dfUPa9sVZT6W9BTXqZq18d51A5zFGZuG7","4ahpNZJ7pVS85f34ErDXwRmckhmbmvT52ed6kr6J66ZA","ENpscuTJCYReY3NnNcRBJnC7S6pAYbxSfAdcdnJjvxN5","G2fWcgYP49p4J1Db8Jnj3KBJrg1fp1DsfzBo4uJb8u4j"]
A list of NFTs, specified as Mint Ids in the values key
1
Candy Machine Id
["2crTqcmVJVMW6b5z6NEs9HdsKmVc4zDDE2FucNg98kSN"]
Use the Candy Machine Id (i.e. First Creator) to define the collection
2
Collection Id
["CcLrhgWz29JRd3TgxSNEeWwMfMoX9Cz1NQXh27aWUMMx"]
Use the Collection NFT Mint Id
whitespace (spaces, tabs, etc)
"_"
pipe (|)
":"
colon (:)
""
forward slash (/)
":"
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |
In order to use the Boot-up CLI you will need the following:
An on-chain collection of NFTs.
The NFTs in this project are configured with a Collection NFT. For more on Certified Collections, please visit https://docs.metaplex.com/programs/token-metadata/certified-collections
The Solana command line toolset (https://docs.solana.com/cli/install-solana-cli-tools) - to interact with the Solana network.
1 $RAIN (Mint Id rainH85N1vCoerCi4cQ3w6mCf7oYUdrsTFtFzpaRwjL
) for each player in your collection.
Review your Player and Item class enabling with Boots
Once you have completed all 4 steps to enable your collection to work with Boots, you can validate what your player and item classes look like by using the Raindrops CLI. First, go to the configuration file that you have been working with. An example of a finished configuration file is in the Examples, here. You will want to copy the Player Class configuration that was generated by Boot-Up
Search for existingClassDef
in the file and copy the object into a new configuration file. We will name this bootsPlayerConfig.json for the purposes of this example.
2. Make sure you know the location of your keypair file. For our purposes, we will name this bootsUpdateAuth.json and put it in the same location as the config file from step 1.
3. You will also need the masterMint. You can find that in the "masterMint" key from the configuration file you created in step 1. For our purposes here we will be using the Mint Id BNpznqP6Rfy8LhPHEQ23qBYFiAueKiXx9jRaW6WnTo1z
4. Use the following command to show the Player class:
The result of this command is the following:
should match the number of NFTs in your collection
Should show the newBasicStats (i.e. mutationLevel) as well as the stringLayers (i.e. BACKGROUND, FUR) that you have specified in your configuration.
Shows Items that can be equipped for the NFTs in your collection.
For more detail on this output, review "creating a Parent PlayerClass"
This section covers the steps to use the CLI to boot-up.
This step creates the classes for the individual items that belong to the collection.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, classes for each of the items that you specified in the configuration are created and populated in the configuration file, ready for your NFTs to be equipped.
Once this command finishes successfully, you can move on to the next step.
To find this, use the following commands:
npm list -g
To find the location of the raindrops CLI on your machine. You will get something similar to the following:
/Users/<your user name>/.nvm/versions/node/v18.8.0/lib
Once you are in the directory specified, make your way to the boot-up example-configs directory, located at
node_modules/@raindrops-protocol/raindrops-cli/example-configs/boot-up
Rename the pandaExample.json file to reflect your project name and move it to the desired working directory
mkdir ~/boot-up
cp ./pandaExample.json ~/boot-up/myProject.json
This file establishes the definition of the boots-enabled configuration of the collection. You will want to keep this file safe, saving often as you go through this process because as you boot-up your collection the configuration is updated with on-chain ids and other configuration items that will be important to complete the process.
Let's have a look at the keys in the configuration file and what they mean
Update the NFT with the new equipped items.
First we need to prepare the payload to create the transaction for the user to sign.
Then we send the payload off to the Boots API
If the resultant licenseState
is "SUB_LICENSE_FILLED"
the user will not be able to proceed.
If the resultant licenseState
is "SUB_LICENSE_AVAILABLE"
the user will need to pay the license fee.
However, if the licenseState
is "NONE"
we can continue to sign the transactions and send a call to the API to update the metadata:
option | description |
---|
The Boot-Up CLI is part of the Raindrops protocol. Install the Raindrops CLI using the instructions , the Boot-Up CLI is included in the raindrops-cli
. Once installed, you will have access to a sample configuration file which works with the Degenerate Trash Panda collection.
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |
This step uses the configuration file built from the previous three steps to build and equip player classes for your collection NFTs.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
PRO TIP: You can break up the running of Step 4 into parallel processes. To do this, do the following:
1) Use an external method to generate your mint list.
2) Divide the mint list into 4 separate lists.
3) Create 4 copies of your configuration file
4) Set the following keys in each of your configuration files:
5) Open up 4 separate terminals and navigate to the folder with your configuration files and wallet. Set up the boot-up step_four_create_players
command in each terminal with a different configuration file for each, like so:
6) Once each job completes, open up the configuration file for that job and update the "runDuplicateChecks" key to true, and then run the job once more to remove excess items.
After you finish "Step 4 - Create Players" and it successfully completes, you can validate using the Raindrops CLI. See the next section for an example of how to verify your Player class.
option | description |
---|---|
-e, --env
Which environment to use (devnet, testnet, mainnet-beta, localnet)
-r, --rpc-url
The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC.
-l, --loglevel
The log level to use (all, trace, DEBUG, info, warn, error, fatal, off)
-k, --keypair
The keypair which is the update authority for the NFT collection
-cp, --config-path
The path to the configuration file
-h, --help
Get help with this command