Yesterday, we announced that Immutable would be supporting multiple zk-rollups to allow all Ethereum games to have access to our platform. In addition to our existing application-specific rollup, we are incredibly excited to be adding support for StarkNet, StarkWare’s new smart-contract-capable rollup.
As part of Phase 1 of our rollout plan, we are releasing a set of auxiliary Cairo contracts to the core NFT trading primitives necessary to launch a project on StarkNet. Developers can now start to permissionlessly build on top of these primitives, and we encourage you to do so early!
These contracts are designed to be feature-rich and recommended standards, generalizable for current and future partner use-cases and the broader StarkNet and Web3 gaming ecosystem. We provide Immutable X compatible, out-of-the-box Cairo contracts to help developers easily onboard and develop on StarkNet.
v1.0 contracts
ERC20
Our Immutable X token ($IMX), alongside GODS, GOG, USDC, and all other current and future ERC20s part of the Immutable X ecosystem, are currently available on both mainnet Ethereum and our StarkEx platform. To be able to port these over to StarkNet, we built an ERC20 token preset in Cairo that accommodates all the features of our existing tokens and was also generalizable enough to be offered to our partners (and the broader StarkNet ecosystem) as a recommended ERC20 standard.
In our GitHub repository, we introduce our ERC20 preset (ERC20_Mintable_Capped.cairo), which features a relatively straightforward implementation of the standard Ownable, Mintable, and Capped extensions, following the examples that currently exist in Cairo and Solidity:
- Ownable - a specified address has administrative privileges over specific actions (e.g. minting)
- Mintable - (only owner) can mint ERC20 tokens to a specified address
- Capped - a maximum supply is defined once on contract initialisation, and the total token supply can never exceed the maximum supply
This implementation is suitable for a standard fixed-supply ERC20 token with a designated contract owner with minting rights and can be used out of the box to kick-start your fungible token projects.
ERC721
Our ERC721 contracts are an implementation of the ERC721 standard alongside various extensions on StarkNet, inspired by the OpenZeppelin’s Cairo implementation with some modifications to support more use cases beyond the original EIP721 specification.
The design formally introduces contract metadata, originally coined by OpenSea, allowing for an NFT collection to have store-front level metadata. ERC721 also uses a felt array to represent strings in StarkNet to accommodate for NFT URIs with more than 31 characters, which is a current limitation of using felts to represent short strings native to Cairo.
We present a recommended preset ERC721_Full in our v1.0 contracts, which implements key functionality such as Role-based access control, Royalties, Token Metadata, and Contract Metadata. This functionality is sufficient for the majority of your ERC721 use cases but is also extensible to new functionality should it be required.
See our full post on ERC721s here >
Royalties
Royalties have been handled in a range of different ways on Ethereum, from centralized royalty systems, and custom on-chain royalty solutions, to the EIP2981 royalty standard. In supporting Immutable X NFTs on StarkNet and ensuring we can trustlessly enforce royalty distributions, we explored different ways to port over the respectively attached royalties to design an ecosystem-wide standard for royalties on StarkNet.
While it hasn’t seen widespread adoption yet, we chose the EIP2981 standard as the most simple, decentralized, and effective solution to define and manage royalties on StarkNet. Since EIP2981 only specifies the royaltyInfo function for royalty calculation, there was the flexibility to experiment with different mechanisms for defining and managing royalty details.
In our royalties article and contracts on Github, we present four versions of royalty implementations (Immutable, Mutable, Unidirectionally mutable, Flagged), each with different degrees of mutability and resulting implications for contract owners and NFT holders.
See our full post on Royalties here >
What’s next?
This is just the beginning of our StarkNet journey and we are working to build more StarkNet primitives to add to this collection of contracts on a rolling basis. Next up an L1 <> L2 ERC721 bridge coming soon!
We welcome StarkNet developers of any level of experience to experiment with our contracts and start building on top of them. Any suggestions, improvements, or feedback would be greatly appreciated — please check out our contribution guidelines on how to get involved!
