Perform a primary sale
Primary sales are the first step towards getting in-game items into players' hands. Among other things, a game studio can utilise primary sales to provide an in-game storefront experience.
Immutable offers a specialised Flow inside the Commerce Widget to help developers integrate primary sales into their game.
- Reduced development time for your game.
- Access to advanced features like VIP allowlists, multi-phased sales, buyer restrictions, and funding tools.
- Expanded reach through additional marketing tools, connecting your game with a larger community.
Why conduct a primary sale?
There are generally two reasons for conducting a primary sale in a web3 game:
- Sales as a means of customer acqusition: This is a tactic of other types of web3 projects, where on-chain assets are used to incentivise future players to discover and support your new project. You can find some considerations for how to manage demand in these primary sale circumstances later on in this article.
- Sales to provide players with better in-game experience: This comes from the storefront experiences you find in web2 games, where players are able to buy weapons, skins, accessories, powerups and lootboxes though a shopping experience. Typically most of these items would be sold at fixed cost, and considerations for rarity is typically item specific.
Methods to platform for a primary sale
Regardless of the above choice in why you're conducting a primary sale, there are two distinct ways of platforming on-chain.
- Direct mint - Includes recommended method, including:
- Using our Primary Sales Flow - using our proprietary Primary Sales tool - highly recommended
- Using a custom primary sales contract - configuring your existing custom contract to work with Immutable zkEVM
- Using a custom POS to backend minting API - using our Minting API feature alongside a custom front-end and purchase experience
- Pre-mint and transfer
- Direct mint to your wallet and then list on Immutable Orderbook - repurpose the Orderbook feature to perform an initial secondary sale
- Ordinary minting and transferring - not recommended
Method 1: Direct mint
This occurs when players directly interact with a smart contract to purchase a game asset. Players send a specified amount of funds to a smart contract during the sale and the contract will then mint an asset directly into their wallet. This approach has advantages such as increasing transparency for players regarding the sale's logic, however the approach needs to be well-thought through and considered as any changes to the primary sale's design could require another smart contract deployment.
There are a number of options to do this on Immutable zkEVM. From our perspective, we would recommend your platforming choice be dependant on how much existing infrasture you've already built. If you're starting from scratch, our Primary Sales Flow is by far the most convenient.
We will take these recommended methods in turn:
Using our Commerce Widget Primary Sales Flow
We are continually developing our Primary Sales Flow, you can now set this up using our Developer Hub. You can follow our instructions here to get started. Here you'll learn how to set up both the front-end and back-end components. You can see a result of how this works from a user experience perspective in our Immutable Playground environment
Today, there's a need to build some custom logic for the following:
- Quote API
- Sale Authentisation API
- Sale Confirmation API
- Sale Expiration API
You can read more about this here in the product documentation. Our presets for this - "simplified" execution - will be available soon.
The benefits of doing primary sales with our Commerce Widget include:
- Easiest to get started as you can initiate backend from Developer Hub
- Optionality to either use "Simple" or "Advanced" with your own back-end logic (coming soon)
- Payment (including fiat and on-chain) and delivery features included out of the box via multiple wallets
- Uses our standard contracts so you don't need to worry about allowlisting
- Smart checkout allows users to swap and pay in one flow
- Supports mobile and desktop browser experiences
Using a custom primary sales contract
To make sure that creators receive their hard earned loyalties, Immutable requires that all collections of ERC-721/1155s deployed on Immutable zkEVM implement the Operator Allowlist. Not implementing will have these effects for your collection (i.e. ERC-721/1155s):
- You may forfeit any token grants you may have received.
- Passport users will receive a warnings that your collection is likely to be counterfeit.
- Your collection will not appear on any of the 3rd party marketplaces in our ecosystem.
For more information on the Operator Allowlist, please see this guide.
If you choose to not use an Immutable preset contract (eg. ERC-721, ERC-1155), you must inherit OperatorAllowlistEnforced.sol.
Instructions can be found here.
Using a custom primary sales contract will allow you to reuse an existing contract but still leverage Immutable's front-end infrastructure as part of the Primary Sales Flow. Additionally, payment (on-chain only) and delivery features are included out of the box.
Using a custom POS to backend Minting API
In this scenario, you'll need to compositely put together a number of pieces of the primary sales infructure. This includes your own front-end experience also and just rely on Immutable for the way we help you streamline cost-effective minting.
The process for using the Minting API here is actually identical to the process we would recommend for a Airdrop Free Mint. You can get specific guidance on this in the Free Mint guide
The benefits of using this method are:
- Supports scenarios where you want to use your current POS architecture for payment
- Our Minting API can help you execute the minting process with more efficiency
- As you're using our Minting API, you are covered under our gas sponsorship program
Method 2: Pre-mint and transfer
This occurs when a game creator initially mints assets into their collection-owned wallet(s) and then transfers those assets to players upon a successful transfer of funds (either fiat or crypto). While this approach allows more flexibility with the sale's design (e.g. does not require a smart contract update upon a change in design), it could come at a potentially greater cost to the game creator if they are required to pay both the minting and transferring gas fees for each asset.
There are 2 main ways to do this and neither are recommended, in turn these are:
Direct mint to your wallet and then list on Immutable Orderbook
Despite this being called "Direct Mint", this method is actually a way of using Immutable's products to conduct a mint and sale (transfer). Our Global Orderbook is intended to facilitate more efficient secondary sale of assets between players and traders. However you could repurpose this infrastructure to sell from you the creator of the asset.
Given the nature of execution here, it is one of the simplest and fastest ways to get a sale going, however, there's distinct limitations highlighted below, therefore we do not recommend this method:
- You can't whitelist user wallets
- You can't time your sale effectively
- You can't offer variable pricing and there's no randomisation
Ordinary minting and transferring (ie without Orderbook)
This is the least desired option as it has a poor user experience and incurs gas costs. We would discourage you from architecting and executing this way.
Pricing considerations and structures for your primary sale
A primary sale can be performed with a fixed price, or a variable price based on auction techniques.
| Mechanisms | Description | Examples |
|---|---|---|
| Fixed price | A fixed price sale is the the most common type of primary sale and the simplest to execute. This occurs when game creators price assets at a fixed price throughout the entire sale's duration. | |
| Auction | Auctions are more complicated to execute but lead to better price discovery of the assets. There are two main types of auctions:
|
Additional information and considerations
As you think through your primary sales decision you should consider the following points. For the average game, we believe you'll need a combination of various architecture which is tailored to your specific sale need.
| Consideration | Description |
|---|---|
| Volume cap | A primary sale that sells out all of its assets is a clear signal of a successful sale. Depending on the type of sale, this can provide your game predictable revenues, as well as drive buyers' interest to the sale as the available supply dwindles. |
| Time cap | Game creators can choose to have a clearly defined sale window for players to purchase their assets. In addition to driving excitement towards the sale starting, this can also drive demand as the sale finishes. |
| Phasing | A phased launch (i.e. holding several launches to distribute an asset's total supply) is a particularly useful lever to drive sellouts and excitement where total asset supply outweighs your current community size. The sequence of game asset sales (e.g. PFP followed by land assets) can also be an important decision as it creates a mental model where participants understand what is being dropped and why without needing to be told. For example, PFPs being dropped before land assets allows players to get a sense of the game world they're entering. |
| Player purchase limits | To prevent bots or a small number of players buying many of the available assets, player purchase limits (identified by wallet address) should be set. While this reduces potential sales, the sentiment impact and risk of price dumps by holders of many assets are worth the trade-off. |
| Allowlisting | Depending on your primary sales' launch goals, allowlisting a subset of players for access to your primary sale can be valuable. Cases where this approach is helpful would be to reward early community members or to promote healthy community engagement. |