Introducing: Opt-In Programmable Royalties (and more) Through Staking by Limit Break

Limit Break Dev
Limit Break
Published in
11 min readJan 10, 2023

Limit Break is introducing opt-in, backwards-compatible, programmable royalties contracts that work on any ERC-721 contract through a novel staking solution. Our initial goal was simply to give creators the power to decide how royalties will be distributed on the smart contract layer, but as you will read below, this release will allow for numerous applications with the potential to radically reshape the NFT landscape.

Importantly, these on-chain royalties are enforceable at the individual token level, meaning each individual NFT can have its own programmable royalties. This system is opt-in, so if a new or existing NFT collection decides to implement this solution, their individual collectors maintain the power to decide whether or not to “stake” and opt-in with their NFT (or, potentially, to opt out).

Version 1 introduces the “stake to opt-in” and “transfer whitelist” model, and Version 1.1 will be a full implementation of programmable royalties and minimum floors. Read the code and documentation in our Github for complete technical details.

The Current State of NFTs

Non Fungible Tokens (NFTs) are a major breakthrough in blockchain adoption, contributing to the rise of the Web3 ecosystem and onboarding legions of new users into the blockchain ecosystem. But if we are being honest, most NFTs in their current form are pretty boring.

The current NFT market is saturated with simple copies of the same smart contracts pointing to JPEGs. With a few notable exceptions, nearly all NFTs are limited to only three features:

  1. They can be owned by a crypto wallet.
  2. They can be traded on NFT exchanges.
  3. They point to an image or a video alongside some optional traits.

Although this simple format was enough for NFTs to break into the mainstream in 2021, it will not be enough for what’s coming in 2023.

Why NFTs Must Evolve

After the NFT art and ‘profile picture’ market exploded in 2021, it suffered a severe contraction in 2022. Although this was no doubt due in part to the global downturn in virtually all markets, particularly crypto, we believe this early-stage NFT market built upon simple decentralized image ownership could never deliver widespread adoption, particularly in NFT gaming. Instead, something more technologically advanced is needed.

Even with an anticipated increase in player-ownership of in-game NFT-based items, we believe NFT technology’s potential to radically transform the game industry can only be unlocked with bold technological changes. We recognize that the lack of control over economic boundaries of in-game item NFTs prevents game designers from developing the kinds of balanced in-game economies needed to take Web3 to the next level.

Compounding these limitations, the NFT industry experienced a new existential threat in late 2022 with exchanges — thirsty for liquidity — moving to ‘zero-royalty’ or ‘royalty-optional trades’ in a battle for liquidity. This industry shift exposed two fundamental flaws in the current structure of the NFT industry. First, despite the Web3 ethos of decentralization and trustlessness, the power structure is fundamentally biased against the many creators and towards a handful of centralized exchanges. Second, the now-dying industry standard of universal creator royalties existed only as a social contract rather than being enforceable on-chain. On this current track, many creators will simply leave the space or avoid entering the space at all.

Limit Break is determined to fuel the evolution of NFTs and thoughtfully lead a gaming renaissance built on top of blockchain technology. We strive to contribute to the NFT community while inspiring other innovators to pioneer new forms of utility and novel mechanics that will power in-game economies and interoperability with other projects.

It is to this end that we announce the community release of our creator-focused smart contracts, a library of NFT contracts featuring an opt-in staking solution that will upgrade pre-existing NFTs and prepare future NFTs for the Web3 gaming revolution.

Moving Forward with Creator Tokens

While architecting a new industry-shifting paradigm through “Creator Tokens,” Limit Break has prioritized two key objectives aligning with Web3 ethos: backwards compatibility and freedom of choice. This is why we make sure that this is an opt-in staking solution, allowing existing creators to adopt our solutions while letting their collectors decide whether to opt-in on an individual NFT level.

The following sections describe the major design principles that shape the Creator Token Contracts Library followed by a how-to guide to using and extending the contracts.

Design Principles

The creator token contracts library is carefully designed around three major guidelines: (1) creator flexibility, (2) immutability, and (3) simplicity.

First, developers and creators should have the latitude to define how their NFTs are used. Without proper mechanisms to enforce the rules of their own smart contracts, developers cannot reliably ensure the user experience or token utility works according to its intended purpose. Transfer whitelists provide a reliable mechanism to enforce rules, which in turn makes the development of complex new features possible.

Second, NFT smart contracts should be immutable and non-upgradeable, providing users guarantees that they won’t be rug-pulled with ever-changing rules or the possible theft of their tokens by the developer. However, NFT projects are dynamic and collections require the flexibility to evolve over time. Staking provides a backwards-compatible, opt-in system that allows developers and creators to immutably upgrade the features of their collections while giving users the freedom to choose whether or not they agree to the upgrade. To be successful, it is imperative that developers align incentives with their community to encourage their community to upgrade their tokens. Ranging from simple to complex, some incentives creators could consider include:

  • Reveal: user mints a vanilla NFT that is not revealed, and it can only be revealed by staking; time-locked or paid unstake could be used to implement re-rolled reveals.
  • Rewards: staked tokens are eligible for premium airdrops, claims, or other community rewards.
  • Rentability: staking old collections to allow users to rent usage rights from token owners.
  • Guaranteed Minimum Floor Prices: staked tokens whitelist only a minimum floor contract to make pricing boundaries enforceable.
  • Equitable Royalty Systems: trustless smart contracts that allow former holders to claim a percentage of future royalties.
  • In-Game Utility: for example, Limit Break’s Adventure ERC721 system can be added to the staked token to support questing and other Web3 game features.

Finally, the library must be simple, elegant, and avoid feature creep to leave more room for creativity and innovation by developers.

How-To-Guide

The following sections are intended to demonstrate some recommended workflows to use Creator Token Contracts in different scenarios. In the following examples, please note that implementations of metadata URI, minting, burning, and other extended features are left up to the developer’s discretion and preferences. The complete set of contracts and documentation can be found on Github.

Scenario 1: Release New Collection With Whitelisted Transfers

This is the simplest possible scenario, where a creator requires only basic ERC-721 but wants to use a whitelist to determine where their token can trade. The following workflow shows the process to develop, deploy, and configure a new collection with a transfer whitelist.

The following code demonstrates a simple example of deploying a new collection with a transfer whitelist capability built-in.

pragma solidity ^0.8.4;

import "@limitbreak/creator-token-contracts/contracts/whitelist/WhitelistedTransferERC721.sol";

/// @dev By inheriting WhitelistedTransferERC721 and assigning the transfer whitelist registry
/// transfers are automatically restricted to callers that are in the whitelist.
contract MyCollection is WhitelistedTransferERC721 {

constructor() ERC721("MyCollection", "MC") {}

function ownerMint(address to, uint256 tokenId) external onlyOwner {
_mint(to, tokenId);
}

function burn(uint256 tokenId) external {
require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner nor approved");
_burn(tokenId);
}

function _baseURI() internal view virtual override returns (string memory) {
return "https://my.nft.com/mycollection/metadata/";
}
}

Scenario 2: Upgrading an Old Collection Using Staking

In this scenario, the creator desires to add whitelisted transfers among other features to an old immutable collection. Token holders choose whether to opt-into the upgrade by staking their old NFTs. The following workflow shows the process to develop, deploy, and configure a collection upgrade.

When users opt into an upgrade, what they are really doing is staking their token in a Creator ERC721 wrapper contract and minting its wrapped equivalent containing upgraded features. This is a simple two-step process requiring two transactions. First, the user approves the Creator ERC721 wrapper contract to transfer their non-upgraded tokens. Second, the user calls the stake(uint256 tokenId) function. The stake function mints an upgraded token with the same id and locks the former token in the contract. This process is visually represented in the following diagram.

When designing the upgraded contract, a key decision for creators is whether or not to make the staked tokens unstakeable. In cases where the developer allows it, users can downgrade their token by unstaking it, burning the upgraded token, and unlocking the original token. There are generally five options:

  • Permanently upgraded tokens — inherit PermanentCreatorERC721
  • Time-locked downgrade-able tokens through unstaking — inherit TimeLockedUnstakeCreatorERC721
  • Paid downgrade-able tokens through unstaking — inherit PaidUnstakeCreatorERC721
  • Freely downgrade-able tokens through unstaking — inherit CreatorERC721
  • Custom downgrade mechanism through unstaking — inherit CreatorERC721 and build your own

The following diagram depicts the unstaking/downgrade process for users.

The following code snippets demonstrate how to extend various types of Creator ERC721 tokens to upgrade a collection.

pragma solidity ^0.8.4;

import "@limitbreak/creator-token-contracts/contracts/presets/PermanentCreatorERC721.sol";
import "@limitbreak/creator-token-contracts/contracts/presets/PaidUnstakeCreatorERC721.sol";
import "@limitbreak/creator-token-contracts/contracts/presets/TimeLockedUnstakeCreatorERC721.sol";

/// @dev By inheriting PermanentCreatorERC721 and assigning the wrapped collection
/// address, a permanent token upgrade can be initiated by token holders.
contract MyUpgradedCollection is PermanentCreatorERC721 {

constructor(address myV1Collection) CreatorERC721(myV1Collection, "MyCollection (V2)", "MC") {}

function _baseURI() internal view virtual override returns (string memory) {
return "https://my.nft.com/mycollectionv2/metadata/";
}

/// TODO: Optionally, add additional utility/features here
}

/// @dev By inheriting PaidUnstakeCreatorERC721 and assigning the wrapped collection
/// address, a token upgrade can be initiated by token holders. Upgraded tokens can
/// be downgraded to the prior version by paying a fee.
contract MyUpgradedCollection is PaidUnstakeCreatorERC721 {

constructor(uint256 unstakePrice, address myV1Collection) PaidUnstakeCreatorERC721(unstakePrice, myV1Collection, "MyCollection (V2)", "MC") {}

function _baseURI() internal view virtual override returns (string memory) {
return "https://my.nft.com/mycollectionv2/metadata/";
}

/// TODO: Optionally, add additional utility/features here
}

/// @dev By inheriting TimeLockedUnstakeCreatorERC721 and assigning the wrapped collection
/// address, a token upgrade can be initiated by token holders. Upgraded tokens can
/// be downgraded to the prior version after a time lock expires.
contract MyUpgradedCollection is TimeLockedUnstakeCreatorERC721 {

constructor(uint256 timelockSeconds, address myV1Collection) PaidUnstakeCreatorERC721(timelockSeconds, myV1Collection, "MyCollection (V2)", "MC") {}

function _baseURI() internal view virtual override returns (string memory) {
return "https://my.nft.com/mycollectionv2/metadata/";
}

/// TODO: Optionally, add additional utility/features here
}

Case Studies

The pattern of whitelisting one or more trusted operators that can execute transfers enables new composable features that were not possible previously. New functionality can now be built around the transfer of NFTs without the need to build custom features directly into the NFT contract itself. Furthermore, these features can be extended or upgraded by simply modifying the transfer whitelist. New features built around NFT transfers could transform Web3 gaming and the NFT industry as a whole. In this section, we feature case studies on two new features Limit Break is actively developing using this pattern in Version 1.1.

Minimum Floor Operator

A specialized Minimum Floor Operator contract will allow creators to define a minimum sale price for NFTs in their collections on either individual tokens or the overall collection.

Elite artists with strong reputations may avoid creating NFT artwork out of concern that their brand will be tarnished if their work sells below the value of their traditional art pieces. Since traditional fine art is generally illiquid, the reduction in liquidity that would likely accompany enforceable minimum sale prices would likely not be of concern for this type of user.

A few examples of how a minimum floor operator empowers game developers include, but are not limited to:

  • The ability to specify a fixed price on a high value game item like a weapon at 100 ETH. Such a weapon will not trade easily and thus reinforces its high value and rarity in game.
  • Building guide rails around how external and macroeconomic factors, like ethereum prices and currency exchange rates, impact the balance of in-game economies, which is already a challenging ordeal.
  • The ability to change the minimum floor with evolving game conditions
  • A fixed price item where players are guaranteed that the value of their items are not affected by speculation.

The most exciting aspect of the Minimum Floor Operator is the power to transform the NFT industry by making on-chain royalties enforceable at the contract level. Even when the minimum floor price is set to zero, enforcing that the control flow and funds from marketplace sales must go through the Minimum Floor Operator contract guarantees that marketplace fees and royalties defined on-chain using EIP-2981 will be honored in a trustless manner, which is how NFT royalties should have always worked.

Enforceable Royalty Sharing

In the past, royalty payments could be shared in a static manner by routing royalty payments to a payment splitter contract that had to be initialized one-time with a predetermined set of beneficiaries and shares. For projects that incorporated shared royalties with NFT holders or affiliates the payments were more centralized, requiring the project to reconstruct NFT sale context off-chain in order to calculate everyone’s share and then actively airdrop to users or establish a claimable dividend fund.

By making royalties enforceable on-chain in a manner that preserves transaction context, the Minimum Floor Operator contract unlocks new possibilities where smart contracts can manage a dynamically changing set of users that are eligible to claim a share of royalty funds, whether at the collection or individual NFT level according to custom rules the developer determines is best for their own community. In general, the project would be able to allocate a percentage of royalties that go to the creator, to affiliates, and to collectors.

For creators and affiliates, royalties can be further subdivided using payment splitters with predetermined beneficiaries and shares. Collector-level royalties could be shared in many interesting and dynamic ways including, but not limited to:

  • Token minter receives 100% of future collector-level royalties on that token
  • Long-term token holders (for example, those that held a token for more than one year) receive either an equal share or a relative share of future collector-level royalties on the tokens they held based on the length of time they owned the tokens
  • Former holders receive collector-level royalties on the tokens they held for some bounded number of future NFT sales where their relative shares are based on the length of time they owned the tokens relative to others

Including collectors as stakeholders for royalties is a powerful way that creators can align incentives with their community of NFT holders. This builds value for NFT collectors that was previously not possible and will work into perpetuity thanks to smart contracts.

What’s Next For Limit Break

Limit Break seeks to use technology and decentralization to keep the power of NFTs in the hands of creators and collectors. The community release of Creator Token Contracts is an important step in that direction. The DigiDaigaku development team is continually expanding the capabilities of the collection and building upon our platform of smart contracts in ways that will benefit the Web3 game ecosystem. Simultaneously, Limit Break is collaborating with exchanges to cement the Minimum Floor Operator as a new marketplace standard because it has the power to transform the NFT industry. We can’t wait to see what creators will build in 2023 and beyond!

We would love to hear your thoughts. Please reach out to blockchain@limitbreak.com with suggestions and feedback.

Disclaimer

Both the Limit Break and DigiDaigaku team are still planning how they might implement these solutions so don’t make any assumptions on how this will work for either team or their products yet.

--

--

Limit Break Dev
Limit Break

Limit Break devs live by a code: be the best and ship, ship, ship!