Choosing the Right Token for your Crypto Application
By Juan Tavira, Senior Blockchain Architect & Identity Expert at Banco Santander.
It took only 4 months after the launch of Ethereum when the first token standard appeared, the ERC-20. That was in 2015 nearly 9 years ago (this article was written in 2024). 9 Years and many projects still use raw ERC-20, not any of their successors; ERC-20 became the de-facto standard for simple tokens even if there are better options. Nevertheless, there are many industries where a simple token is not enough.
What about NFTs, the ERC-721? They suffer the same problem. The original standard is still used and abused.
And the problem is that many times, both are deployed with non-standard modifications that affect their reliability. You can read a bit more about the basic tokens in our article:
Some examples of token modification failures, but with a reason
In 2023 Societe Generale-FORGE announced a euro-pegged stablecoin. The SmartContract had some vulnerabilities even though it was audited. Why did they introduce the changes that lead to the vulnerabilities? Because they were covering legal aspects for emitting CoinVertible, their stablecoin.
You can read more details here and here.
Many people think that blockchain should be ruled only by the SmartContracts (“code is law”) and the community decisions. But the information, behavior and services of SmartContracts would be inaccessible to the casual user then. That’s why companies started offering services on Blockchain and that companies’ activities should be guaranteed by the governing law ⚖️, protecting the users. Societe Generale added features like two-step role transfer, whitelisting, etc., to follow the regulation.
Talking about regulation the first step in any token-related project would be to review the regulatory standards and recommendations. In Europe 🇪🇺 MiCA would be the starting point; In USA 🇺🇲, the SEC recommendations.
Surely if you are issuing a token with market exposure you will have to cover KYC, AML and much other requirements.
Are there any new standards we can benefit from?
Of course. It is not only the technical benefits of newer standards, but the matter is also what new standards comply (or helps you to comply) with regulatory requirements.
Then, whenever you have some clues on the requirements of your token, you can follow with the implementation standards. We’ll cover here 👇 a few examples on the token structure and the functionality offered.
Token structure evolution standards:
Token structure refers to the basic structure and capabilities of the tokens. For example, ERC-20 tokens are just a number of a kind of asset assigned to an account whereas ERC-721 (NFTs) has individual (non-fungible) tokens, each one different of the others, with unique attributes each one. What is new in this field?
🔸 ERC-1155: Multi Token Standard
This new standard was intended as a better tool 🔧 for token issuers. While previously each ERC or NFT required its own SmartContract this could be an overwhelming work for those projects that required lots of different tokens. ERC-1155 allows in a single SmartContract to manage several ERC-20 and NFT tokens, and it also has the helpful batch transfers.
Next to ERC-1155 things start to become interesting as the structure of tokens gain in complexity…see what we got.
🔸 ERC-7401: Parent-Governed Non-Fungible Tokens Nesting
ERC-7401 (an update of ERC-6059) is behind the idea of extending NFT capabilities so an NFT can own other NFTs and ERCs-20 (but an ERC-20 cannot own an NFT). This is called “nesting” 🪹. Nesting for NFTs works the same as sending the NFT to a user, with a transaction from the parent token account owner. A tree-like structure.
This standard offers bundling several contents in a single token, organizing collectible content, grouping membership and that membership benefits or even vote delegation by transferring the relevant token of a DAO membership. Everything done via grouping several tokens under a root NFT.
Obviously, the nesting feature of this ERC-7401 requires of a proper management: Child token management. The transferChild 🧒 function has different state transitions to achieve it: Reject child token, Abandon child token, Unnest child token, Transfer the child token to an External Owned Account (EOA) or an ERC721Receiver, and Transfer the child token into a new parent token.
It is interesting to see how this standard resembles a managed tree structure like the ones every programmer learns at the beginning of their career. We’ll probably see in a few years more complex data structures to hold tokens.
Token functional enhancement standards:
The same way that ERC-20 and ERC-721 have quite simple structure they also have very simple functions: minting, transferring, burning, etc. None of the related to the regulatory requirements for example. Some new standards have appeared to cover those gaps:
🔸 ERC-2981: NFT Royalty Standard
NFTs may represent real world assets, digital art 🧑🎨, collectibles, and most of them have a monetary value. What happens to artists who created the NFTs? Do they get profit only from selling the NFT or should they also get royalties? Some marketplaces already offered royalties over the NFTs sold in their platform but when the NFT was sold in other platforms royalties were not considered. This new standard homogenises the royalties putting them in the marketplace independent SmartContract.
🔸 ERC-3643: T-REX — Token for Regulated Exchanges
This is probably the first token standard designed with the regulation in mind. When it comes to tokenized securities or security tokens, the situation is more complex than simple tokens, due to the need for compliance with securities laws. These tokens cannot be permissionless like utility tokens; they must be permissioned to track ownership and ensure that only eligible investors can hold tokens.
However, ERC-3643 applies only to ERC-20 tokens, so NFT alike tokens are out of the scope. It covers the following requirements:
◾ MUST be ERC-20 compatible.
◾ MUST be used in combination with an on chain Identity system.
◾ MUST be able to apply any rule of compliance that is required by the regulator or by the token issuer (about the factors of eligibility of an identity or about the rules of the token itself). It covers receiver whitelisting.
◾ MUST have a standard interface to pre-check if a transfer is going to pass or fail before sending it to the blockchain.
◾ MUST have a recovery system in case an investor loses access to his private key.
◾ MUST be able to freeze tokens on the wallet of investors if needed, partially or totally.
◾ MUST have the possibility to pause the token.
◾ MUST be able to mint and burn tokens.
◾ MUST define an Agent role and an Owner (token issuer) role.
◾ MUST be able to force transfers from an Agent wallet.
◾ MUST be able to issue transactions in batch (to save gas and to have all the transactions performed in the same block).
ERC-3643 is considered the standard for compliant Real-World Assets (RWA) Tokenization. RWA are the onChain representation of assets in the real world like gold, properties 🏘️, mortgages, etc.
ERC-3643 de facto replaces ERC-2020 E-Money Standard Token that is in stagnant status. It competes directly with ERC 1400 — The Security Token Standard that adds some capabilities like Settlement, Custody, Aggregated Entity Balances, etc. ERC-1400 belongs to a private company and it is not listed in the official Ethereum proposals.
🔸 ERC-4626: Tokenized vault standard
A token vault is an SmartContract where users deposit their tokens (typically ERC-20) to participate in a DeFi platform and get profit from their tokens. When a user deposits his tokens he gets in exchange some vault tokens, representing his share in the pool of assets.
Vaults are considered very secure 👮 because of their SmartContract design (they may require, for example, multi-sig for some operations). But there’s the burden of integrating different tokens and the risk of potential security exploits.
ERC-4626 is a standard to homogenise developments of Token vaults, extending the ERC-20 and adding feature like:
✅ Deposits and redeems.
✅ Conversion rates.
✅ Vault balances.
✅ Interfaces.
✅ Events.
🔸 ERC-4519: Non-Fungible Tokens Tied to Physical Assets
This standard was developed because NFTs (EIP-721) only tracks ownership (not usage rights) and does not track the Ethereum addresses of the asset. As the popularity of smart assets, such as IoT devices, is increasing; in order to permit secure and traceable management, these NFTs can be used to establish secure communication channels ☎️ between the physical asset, its owner, and its user. Really interesting approach in the IoT & blockchain field.
🔸 ERC-7092: financial bonds
This proposal introduces fixed-income financial bonds with key characteristics defined to facilitate bond issuance in the primary market and enable buying or selling bonds in the secondary market. The standard also provides cross-chain functionalities for bonds operations and management across multiple blockchains. Let’s see 👀 some of its capabilities:
👉 Identity Registry
The standard does not manage the holders’ identity, but the Identity Registry is an optional piece that may store the identity of all authorized investors to enhance transparency and meet regulatory requirements. ⚠️Be careful with personal data , it should never reach the blockchain network per GDPR restrictions (this does not apply to company data).
👉 Security Considerations
The implementation of bonds following this kind of tokens require careful attention to security risks regarding operations to be executed only by owner of approved accounts.
Finally
The road into your token does not finish here, this is just the beginning. Your project will probably require some bespoke additions to the SmartContract so do not forget to follow strict development procedures, quality control and security testing for avoiding being in the newspapers 📰 as a new DeFi.
Draft or Under Review token standards:
🔸 ERC-6960: Dual Layer Token
Token with a two-level classification system using mainId and subId. Intended to help Real World Assets (RWAs) tokenization and fractionalization allows an asset to be represented as a Main Asset (with its own total supply) or in several sub assets, that share the main asset id (MainID) and each one has its own SubId and amount (totaling the main asset total supply). Let’s see an example:
This seems to be a nice addition to ERC-20 and NFTs but somehow has been superseded by ERC-7401 that cand handle complex token structures. Also the standard does not cover rules such as “sum(sub-assets.Amount) = Main-Asset.Total supply”
🔸 ERC-6551: Non-fungible Token Bound Accounts
This proposal defines a system which assigns Ethereum accounts to all non-fungible tokens. These token bound accounts allow NFTs to own assets and interact with applications, without requiring changes to existing smart contracts or infrastructure. The proposal aims to give every NFT the same rights as an Ethereum user.
🔸 ERC-4337: Account Abstraction Using Alt Mempool
This ERC could be seen as an utility over tokens as itself does not define a new token standard but a new usage of existing tokens. Account Abstraction is a mechanism that allows the payment of a transaction fees by a third party.
Before you go:
Clap if you liked it 👏, comment and share this article to reach more community 🧞.
Would you like to be part of our technology project? Find our open vacancies worldwide here 👉 https://www.betechwithsantander.com/en/home
