Considering Token Standards

Part 3/4 // Tokenomics Focus // October 2022

As part of this month’s focus on tokenomics design, our research team has discussed the considerations that precede a token launch or the integration of tokens into a project ecosystem:

Finding a relevant token model, specifying the token design, and outlining allocation and distribution are critical steps (outlined in part 2 of this series). But, our engineering team has interjected. A linear design approach negates a critical understanding of token standards that must be embedded in all steps of the process.

According to our smart contract lead:

“The capabilities of a token (as established by its standard) and our understanding of predominant token models go hand-in-hand. It would be more difficult (or at least take a little longer than necessary) for a financial engineer to design a token concept without any understanding of existing token standards to help guide their thinking.”

Indeed, it would be naive to work on the representation of limited-run assets without considering the attributes of the ERC-1155 batch standard, for example.

While these standards are voluntary, adhering to them ensures compatibility with a wide variety of applications including exchanges, dapps, and wallets. At Verum Capital, our developer, design, and financial teams work closely on token related projects so that we can ensure the feasibility of our design in any ecosystem. Our team has worked on token-enabled business models on Ethereum, Polygon, Fantom, Algorand, and Solana. So, we present here an overview of the standards we consider most valuable when working in these ecosystems. This list in not a technical resource. Rather, it is index of standards to keep top-of-mind as your team works through a token design process.

Ethereum

ERC-20: Standard Fungible Token

ERC-20 is the standard used for creating and issuing smart contracts on the Ethereum blockchain. It allows developers to create their own tokens. Designed for payments, they are widely used as utility tokens because of their key features (fungible, transferable, with fixed supply) and have become the most commonly used tokens used on Ethereum network. ERC-20s are widely used including projects like Chainlink, Tether, Maker, Augur.

ERC-721: Non-fungible Standard

ERC721 is a standard for representing ownership of non-fungible tokens, where each token is unique. This type of token is perfect to be used on platforms that offer collectible items, access keys, lottery tickets, numbered seats for concerts and sports matches, etc. It was invented as a “deed”, because possession of the token indicates ownership of whatever it represents.

ERC-1155: Multi Token Standard

The two major token standards on Ethereum were ERC-20 and ERC-721 for fungible and non-fungible tokens respectively. These tokens represent the gold standard in their domain. However, they cannot be wrapped into the same smart contract. Enter 1155. Effectively, the 1155 standard combines attributes of the 20 and 721 standard to increase efficiency and reduces costs when it comes to making highly tradable and semi-fungible assets.

1155’s have many applications. Gaming and NFT marketplaces are making good use of the standard:

• Horizon uses the 1155 standard in their Skyweaver game.
• OpenSea’s marketplace has an ERC-1155 implementation that allows multiple creators per smart contract but only one creator can mint more copies.

ERC-777: Token Standard

ERC-777 presents a more advanced version of the ERC-20 standard for fungible tokens. ERC-777 introduces a new classification of addresses known as operators, an exchange for example, who can send tokens on behalf of another address. Within this framework token holders to easily authorize and revoke permission from particular operators who might send and receive tokens on their behalf. As of August 2021, the ERC-777 token standard is one of only a small batch that has achieved a finalized status in the Ethereum community, though it is still not used nearly as often as the de facto gold standard ERC-20.

ERC-1400/3643: Security Tokens Specifications

The 1400 standard was developed by Polymath to provide consistency in the delivery of security tokens. It combines new and existing standards to create a unified framework for all security tokens. It is comparable to the ERC-3643 (formerly T-REX). While 3643 offers a number of features as a permissioned token standard, the 1400’s key benefit is that it is partially fungible.

ERC-165: Standard Interface Detection

ERC-165 creates a standard method to publish and detect what interfaces a smart contract implements. It standardizes how interfaces are identified, how a contract will publish the interfaces it implements, how to detect if a contract implements ERC-165, and how to detect if a contract implements any given interface. It is very useful for listing tokens on exchanges because it helps the operator identify which standard is implemented in the contract (ie. ERC-721 vs ERC-1155).

ERC-2981: NFT Royalty Standard

The 2981 standard allows contracts, such as NFTs that support ERC-721 and ERC-1155 interfaces, to signal a royalty amount to be paid to the NFT creator or rights holder every time the NFT is sold or re-sold. This is intended for NFT marketplaces that want to support the ongoing funding of artists and other NFT creators. This standard can enable a number of unique royalty functions:

• Fixed royalties — this is expected to be the common case where a static percentage is used for every sale.
• Decaying royalties — reduce royalties owed for every transfer event of the NFT over time.
• Multisig royalties — the receiver address could be a multisig smart contract. It may represent a DAO or some effort towards public goods funding
• Stepped royalties — don’t send royalties if the sale price is below a threshold

ERC-3525: Semi-Fungible Token

The ERC-3525 standard combines features from EIP-20 and EIP-721 to offer a semi-fungible Token solution, in which tokens with the same “slot” value become fungible tokens, while tokens with different “slot” values become non-fungible tokens. This overcomes the problem of the ERC-20’s inability to carry a lot of data and the ERC-721’s lack of liquidity. An example of 3525 in action is Solv Protocol.

ERC-4907: Rental NFT, an Extension of EIP-721

ERC-4907 adds a new feature to the NFT standard, separating the owner from the user of the NFT, which makes it possible to “rent” and NFT. The renter can use the NFT for a fixed term, upon which the NFT is automatically transferred back to the owner. Owners no longer have to manually withdraw user rights, eliminating a tedious process and another on-chain transaction. An example of 4907 in action is Double Protocol.

ERC-5192: Minimal Soulbound NFTs

The 5192 standard is another extension of EIP-721. It proposes a minimal interface to make tokens soulbound using the feature detection functionality of EIP-165. A soulbound token is a non-fungible token bound to a single address. It is not yet widely used but has anticipated use cases in education credentials, job applications, and health records.

ERC-4626: Tokenized Vaults

ERC-4626 is a standard to optimize and unify the technical parameters of yield-bearing vaults. A vault is a multi-sig solution or smart contract that can store and manage assets such as crypto. The problem developers face concerning yield-bearing tokens is integrating tokens of different protocols. The main benefit of ERC-4626 is that it standardizes tokenized vaults to make protocol integration easier and less prone to error.

Algorand

Algorand Standard Asset (ASA)

On the Algorand network standards tokens and on-chain assets are created as an Algorand Standard Asset. ASA’s are a Layer 1 feature that allows users to represent any asset on the Algorand blockchain, offering the same level of security and ease of use as Algo, including speed and security, minimal transaction fees, and low-cost execution.

Unlike Ethereum standards ASA include a number of parameters that allow them to take many forms including fungible and non-fungible. They can represent represent stablecoins, loyalty points, system credits, and in-game points. are very fast and secure, as they are built directly into Algorand’s Layer-1. Due to Algorand’s miniscule transaction fees, they are also low-cost to execute.

Polkadot

Polkadot Standards Proposals (PSP)

The Polkadot ecosystem requires its own standards to fit ecosystem needs. These standards go through several acceptance phases and endeavour to engage the entire community. Existing standards proposals include:

PSP22 — Fungible Token Standard​

The PSP22 Fungible Token standard is inspired by the ERC-20. It targets all parachains that integrate pallet-contracts to enable Wasm smart contracts. It is defined at the ABI level. So, it should be used for any language that compiles to Wasm (and is not restricted to ink! specifically).

PSP22 enables a predefined interface for specific token standards to ensure exhaustive logic is implemented. It will also encourage sharing the most performant & secure implementation.

This standard was the first to be accepted by the community.

PSP34 — NFT Standard​

Creating a standard for a non-fungible token is important in order to avoid different signatures and types of contract that would make interoperability possible. PSP34 aims to resolve this by defining one interface that shares the same ABI of permissionless methods between all implementations.

Solana

Solana Program Library

Solana’s token program defines a common implementation for fungible and non-fungible tokens.

The Solana Program Library (SPL) is Solana’s collection of on-chain programs, which target the “Sealevel” parallel runtime — one of eight key Solana technologies. A common implementation for fungible and non-fungible tokens on its blockchain is defined by Solana’s “Token Program”. Benefits of SPL include:

• When it comes to SPL tokens, they cover both fungible and non-fungible tokens.
• Solana SPL CLI tooling enables you to create tokens without Rust programming.

Hedera

Hashgraph is a distributed ledger technology that has been described as an alternative to blockchains. It has several standards of note:

HIP-18: Custom Fees on Hedera Token Service

Custom fees enable tokens on Hedera to be used for things like utility fees in applications that support their own fungible token or perpetual royalties for NFTs. Three types of custom fees can be specified by the creator:

• Fixed Fee: transfers a set number of tokens, collected as a fee, every time a token transfer is initiated.
• Fractional Fee: A fractional fee can be configured so that it is enforced by any relevant transaction. The amount is determined by setting a numerator and denominator to determine the fractional fee. These fees can be configured to impose minimum and maximum limits on the amount transferred.
• Royalty Fee: A royalty fee can be configured on the fee schedule of an NFT and sent to the associated fee collector account during the transfer of ownership. This fee is defined as a fraction of the fungible token value used in exchange (HBAR or a custom fungible token) for the NFT, as defined by the fee schedule of the NFT. The fee is collected from the receiver of the NFT in a transaction and sent to the NFT’s fee collector account, as defined in the fee schedule.

HIP-17: NFTs on Hedera Token Service

NFT Creations: Token class is defined and each instance (token) within that class shares certain properties but differs on others — these other properties could be, for example, the numbered edition of a series of cards or artwork. Each NFT is expected to not be equal in value between different instances. It’s encouraged that all developers creating NFTs on Hedera adopt this new standard.

HIP-10: Token Metadata

Token Metadata JSON Schema, everyone can append metadata to any token by creating a JSON file using the schema outlined in the specification. It’s recommended that the JSON file be uploaded to an immutable and decentralized storage network, such as Filecoin, and the URI once uploaded be included in the NFT’s memo attribute.