(By Gesso Labs)
Our recent series of articles has focused on the power of native tokens to drive business goals (token rewards), and community value (token utility).
But many projects have hit pause on tokens given the regulatory concerns and ambiguity around them being deemed investment contracts (i.e. securities).
Interested in reading more on regulation, check out our post on launching a token that isn’t a security.
The most widely discussed method in Web3 to launch a token with less regulatory risk is to be sufficiently decentralized. However, decentralization is hard and often a long, incremental process.
This post is focused on a more straightforward path: transfer restricted tokens (tokens that can only be earned and redeemed, but that are not freely tradable on exchanges). In a future post, we will go into the legal and regulatory details, but for now, we will cover how they work and the benefits they can provide.
What exactly is a transfer restricted token (TRT)?
A TRT is a token that has limitations on, you guessed it, how it can be transferred. Utilizing the transfer function within the ERC-20 standard (the fungible token standard on Ethereum and EVM compatible blockchains), there are two types of transfer restrictions that can be applied:
- Blocklist: allowing the token to be transferable anywhere except for specifically listed addresses
- Allowlist: allowing the token to be transferable only to or from specifically listed addresses
You can think of this as follows:
Blocklist = “approved by default” unless expressly prohibitedAllowlist = “prohibited by default” unless expressly allowed
So how can these two approaches be utilized?
- Blocklist: NFT collectionsNFT collections banning marketplaces that don’t honor creator royalties (Tyler Hobbes and Dandelion’s recent QQL drop is an example)
- Allowlist: Native tokensNFT projects and other web3 brands that launch native tokens with transfer restrictions in order to prohibit the token from being bought and sold on an exchange as a way to address legal or compliance concerns
What are the pros and cons of the two approaches to transfer restrictions?
Blocklist
- Pros: more freedom for token holders and external buildersToken holders may send, exchange or sell tokens as they see fit, unless a specific address is expressly blocked. Developers are able to “build permissionlessly,” creating dApps where the NFT or token is used, or enabling the token to be accepted as a form of payment without requiring the project’s permission.
- Cons: more risk and less control for projectsSince all addresses are approved by default, blocking is usually a reactive step to transfers that the project would have wanted to prohibit. For instance, an NFT collection may block marketplace addresses that don’t honor creator royalties, however if after the NFT is minted, 3 additional marketplaces make creator royalties optional, it would require the NFT contract to be updated with those additional addresses to maintain the desired outcome (and this is assuming the contract is mutable and can be adjusted post-deployment).
Allowlist
- Pros: more control for projectsThe project can rest assured that tokens may only be transferred to or from addresses they have expressly approved, ensuring that non-compliant use cases are prohibited.
- Cons: less freedom for token holders and external buildersThe token contract owner (i.e. the project) must define & manage all accepted use cases for the token.
If your goal is to reduce regulatory and securities risk, using an allowlist is the better approach as it ensures that the token cannot be put onto a decentralized exchange (DEX). Since new DEXs may pop up after the token is minted, the blocklist approach may have gaps in coverage, which would pose potential regulatory issues.
Are transfer restrictions permanent?
The short answer is no, transfer restrictions do not have to be permanent. A project may choose to launch a token with transfer restrictions to address certain needs they have at the outset, and remove those transfer restrictions later on. This can provide greater optionality to the project as well as more time for them to build out token utility in support of a healthy token economy, work towards sufficient decentralization (if that is a goal), and create a distributed token holder base while awaiting more regulatory clarity.
Now that we understand how transfer restrictions work, let’s address the question–can transfer-restricted token unlock token reward and token utility benefits to projects and their communities?
TL;DR: 100%
As a recap, token rewards are how someone may receive (or earn) the token, and they are an incredible tool for projects and web3 brands. Token utility is the value someone receives by having the token.
Below is a breakdown of token reward and utility categories and whether they are achievable with TRTs:
On the rewards side, what you will notice is that all of the token reward categories are achievable with a TRT. In fact, TRTs combined with the allowlist approach can give projects more control to craft strong incentives that tie to their business goals. Since the token can be designed to only be earned, and not bought or sold, a project can strongly encourage specific behaviors and actions by community members related to acquisition, engagement, retention, and value-added contributions.
On the utility side, most of the token benefits are achievable, except for financial utility (since it will not be sold on an exchange in order to reduce compliance risk). The token may be used as a form of payment, but only in ways approved by the project (vs. permissionlessly).
One of the unique utility use cases for TRTs is identity. If the token cannot be purchased, then it can truly reflect someone’s contributions and community loyalty, thereby serving as a better representation of someone’s value within an ecosystem.
Hopefully, you now have a better understanding of how transfer restrictions can be used to customize a project’s token design and implementation.
All Comments