Introduction

We are all familiar with tokens, NFTs, and the classic token standards, such as ERC-20 and ERC-721, on which they are based. Specifically, ERC-20 is designed for fungible tokens, while ERC-721 represents a standard for non-fungible tokens and is suitable for artworks or rare assets. That said, how are these tokens implemented? How can they be applied to the relevant applications?

Today, we will go through the principles, scope of application, and future trends of these token contracts, covering token standards that include ERC-20, ERC-721, ERC-1155, and the recently finalized ERC-3525.

(Codes concerning ERC-20, ERC-721, and ERC-1155 are from OpenZeppelin, and the ERC-3525 token is from Solv Protocol)

Hash Table

Before going into the principle of token contracts, we must first address one critical concept: hash table (mapping). Simply put, a hash table is a data structure for mapping that allows us to quickly find values based on keys. Token contracts use hash tables to store information about assets and authorized persons. For more specific information about hash tables, please refer to: https://en.wikipedia.org/wiki/Hash_table

Data Hashing & Functionalities

Tokens conduct data hashing in different ways. The data hashing approach determines the functionalities of a token and can be regarded as the way how assets are structured and recorded. Depending on the specific purpose, data hashing can be divided into the general account and the individual account. The general account records the overall asset status of the token (its type, number, and authorization) and also contains the settings of the authorized persons/admins (authorized persons may freely transfer/re-authorize the assets of the asset owner).

In this context, functionalities refer to the token-based design of data hashing and the achievable functionalities of tokens (i.e. public functionalities), including the query & transmission, minting, and burning of assets.

In the below paragraphs, we will review different token standards in terms of their data hashing & functionalities.


ERC-20

1. Data Hashing

General account: ERC-20 manages and records the overall token assets through a hash table: Mapping (address => uint256). In particular, the Key is the user address, and the mapped Value is a positive integer used to record the number of tokens owned by each address.

Individual account: Thanks to its own simplicity, ERC-20 can record all assets using only one hash table. As such, only one table is needed to register the authorized persons of the individual account. This table uses a single address as the key to map to another table which targets keys that are positive integers: 

Mapping(address=>(Mapping(address=> unit 256))

For example, 0x1 is a Token A account and can authorize other accounts (e.g. 0x2, 0x3) to use its tokens on its behalf. It should be noted that the amount limit of such authorized accounts is only valid when set by the account where tokens are contained (in this case, 0x1).

2. Functionalities (basic)

ERC-20 offers almost all the conditions required for circulation and for tokens to be used as equity and commodities. Plus, the standard also enables ease of use.

ERC-721

1. Data Hashing

General account:

The table maps positive integers to addresses. Here, the ID is the key, and the address is the value. In addition, each ID only corresponds to one address, which achieves the uniqueness and rarity required by NFTs.

Individual account:

Compared with ERC-20, which records the asset balance of all addresses using one table, ERC-721 adds a second table that contains the asset records of individual accounts. In this table, the individual address is the key, and the number of NFTs held by addresses is the value. It records the total NFT holding of each address. However, the table does not record the specific ID of the NFTs held by individual accounts, and the ID can only be obtained through event queries.

In terms of the authorization of authorized persons, with ERC-721 tokens, an individual account comes with an overall authorized person, and this authorized address can operate all the contract tokens contained in the account

Mapping(address => (Mapping (address => bool))

Only the individual account can give such authorizations.

On the other hand, an NFT with an ID can also be independently authorized: Mapping (uint256=>address), and the authorized person can operate the corresponding NFT. In this case, both the NFT holder and the overall authorized person can grant such authorization.

All in all, an individual address can have an unlimited number of authorized persons, all of whom can change the authorized persons of the IDs of the individual address. An individual ID, on the other hand, can only have one authorized person/ address.

For example, 0x1 owns three NFTs in one NFT series that correspond to three IDs: 1, 2, and 3. In this case, 0x1 grants permission concerning the NFTs to countless individual addresses. If it authorized 0x2, then 0x2 would be able to transfer the three NFTs. Meanwhile, 0x2 would also be able to grant the transfer permission of an ID (e.g. 1) to another address like 0x3. At this point, 0x3 could transmit the NFT that corresponds to the ID in any way he sees fit.

ERC-721 ensures the uniqueness and rarity of digital artworks by making sure that one id corresponds to only one artwork that can only be owned by one address. In addition, collectors may also collect multiple IDs of the same series and check the number of NFTs they own. However, ERC-721 contracts do not support the query of the IDs of all NFTs held by one address, which is a feature that’s possibly a restriction motivated by gas consumption. For example, 0x1 holds two NFTs of the same series. Although we can tell that the address holds two NFTs through the contract functionality, we cannot determine the specific NFTs it holds. For us to determine the specific IDs of the two NFTs, we must resort to the log/event of the contract.

ERC-1155

1. Data Hashing

In ERC-1155, both the overall account and the individual account are implemented simultaneously. With ERC-1155, tokens are recorded using a Mapping whose address points to Mapping.

Here, we found an interesting fact: The design of ERC-1155 is actually a kind of fusion between ERC-20 and ERC-721. As such, ERC-1155 can be regarded as a token management solution that combines multiple ERC20-based and ERC721-based tokens (amount set to one, and each address only corresponds to one amount).

With respect to authorization management, ERC-1155 does not feature authorization for individual IDs, and it only allows users to grant full authorization of individual accounts, which simplifies authorization management.

2. Functionalities

To sum up, we noticed that ERC-1155 is not strictly a token standard, but a management solution of tokens. The overall contract does not even have a Name or Symbol. Besides, one ID can be owned by multiple addresses at the same time, which allows an ID to be either fungible or non-fungible. As such, ERC-1155 can be applied in scenarios where multiple types of tokens are demanded. For instance, in blockchain games, items including non-fungible coins or materials and unique legendary weapons can all be achieved using one ERC-1155 contract. In addition, the standard can also be adopted by comparatively small ecosystems, such as the LP Token ecosystem of DEXs.

At the same time, since ERC-1155 introduced the concept of value, if one person can only own one ID, a setting that could be achieved through future contracts, then ERC-1155 could become a version of ERC-721 that features numerical values (i.e. Semi-Fungible Token). This means that ERC-1155 makes NFTs updateable. For instance, in terms of credit, the standard allows users to update their credit score and facilitates the establishment of multi-credit behavior systems that describe each aspect of a person’s credit status with a numerical level.

Despite that, we believe ERC-1155 is not suited for the management of token systems within big ecosystems as its authorization management is way too simple: In ERC-1155, there is only full authorization; you cannot give the permission to operate an ID, nor can you set the maximum quota. Plus, ERC-1155 also has no complete individual account record. In other words, you cannot map all the assets that correspond to the relevant ID using the individual address as the key, and that information is only available through log/event.

ERC-3525

Although ERC-3525 is a comparatively more complex contract, it offers a complete range of functionalities and records, as well as high customizability.

1. Data Hashing

General account: ERC-3525 built an innovative struct called TokenData, which is used to describe an ID. For those of you who are not familiar with codes, this struct can be regarded as a description card of an ID that contains the ID, Slot (a major innovation of ERC-3525), token amount, everyone, the authorized person (there can only be one authorized person), and the authorized address that can spend the ID’s balance.

With this card, we can record the information of each ID, and then put the cards in a list called _allTokens to have them saved.

_allTokens: [ TokenData, TokenData, TokenData………… ]

That said, how is a card located when we wish to check it out? ERC-3525 maps an ID to its struct location in the list. For example, if the location of ID 214 is 1, then _allTokens[1] would lead us to the target card in the list. The _allTokens list records the status of all ERC-3525 assets.

In terms of ID authorization, ERC-3525 adds the goal of numerical values. That is to say, it marks the maximum quota by different addresses using ID as the key.

Individual account: ERC-3525 builds an AddressData card and a hash table to manage individual accounts. The card includes a list of the IDs of the owned Tokens, a hash table of the locations of the owned IDs in the overall account list, and a hash table of the authorized persons of the account. In other words, the card records of the ID held by individual accounts (the IDs are all recorded) and the authorized persons of the accounts.

Subsequently, a mapping is used to record the corresponding card information (AddressData) using the individual address as the key.

Slot

Generally speaking, ERC 3525’s data record is comprehensive and well organized. Despite that, so far, other than better-documented records, the standard isn’t much different than ERC-1155. This brings us to Slot, a variable added to the ID card. It is Slot that makes ERC-3525 highly customizable and enables functionalities that are not available in ERC-1155.

Simply put, like AddressData and TokenData that we introduced earlier, Slot is also a struct. However, in ERC-3525, Slots are customizable. In other words, developers can add any number and any type of variable to Slot according to the specific product demand. For example, in the case of a convertible bond on Solv Protocol, the information that Slots can contain includes Maturity Date, Conversion Price, and Convertible. This Slot, combined with variables such as ID (#6800) and Balance (2,400 USDC), allows developers to create a convertible bond NFT.

2. Functionalities

Since ERC-3525 covers comprehensive accounting records, it offers a wide range of functionalities and leaves us more room for imagination. In particular, a key feature of ERC-3525 is that it realizes the transfer of ID values and the transfer of values between IDs owned by individual addresses, which unlocks more possibilities for NFTs.

For example, with the transfer of ID values, NFT can update its own value status. For credit and soulbound NFTs, a simple ERC-721 that does not support the transfer of values fails to meet all functional demands. Individual credits are always changing, and ERC-3525 can change the relevant values to reflect the changes in individual credits. Or, this feature can also be applied to NFT positions like those in Uniswap V3, allowing users to update the size of their position in a more convenient way. That said, ERC-1155 can also be used to achieve this functionality, and all we have to do is to set the number of owners of each ID to one address (although this is not the case in terms of the Data Hashing structure, it is achievable subsequently), which allows us to transfer/update values under ERC-1155. Moreover, ERC-1155 comes with a simpler design. Plus, it is more applicable under scenarios where multiple types of tokens are demanded.

The value transfer between the IDs owned by individual accounts is the biggest difference between ERC-3525 and ERC-1155 and ERC-721 in terms of functionality. This functionality is valuable in finance. For instance, it could be adopted to achieve the rollover of two delivery contracts with different durations or the switching between different financial accounts (e.g. from spot to futures, which resembles the design of CEXs). Under such scenarios, each ID is turned into a financial account. Meanwhile, Slot is used to record the account information, and the value represents the account balance. Another example is the Range management (in addition to the value) in Uniswap V3. In this case, the Range can be recorded through Slot, and when an individual user wants to change the Range of his position, the platform could respond to the request by transferring the value between IDs.

There are also some place that doesn’t be considered in ERC-3525 standard. For example, in ERC-3525, the name of IDs cannot be manually edited. The names must start from zero and follow a sequential order. In other words, the ID name of a new NFT in a collection is always N+1, with N being the existing number of NFTs in the collection. This is possibly a way to avoid overlapping IDs or to facilitate easier ID management. Furthermore, in some extensions, although ERC-3525 records Slots and puts them in order, it does not support Slot-based id classification/query. In our view, such classification/query methods could be valuable for many products and use cases. For example, bond products can record the information of different bonds through Slot before issuance. If Slots are used to separate bonds with the same Maturity ID, we could build more convenient and functional transaction/management products. At the moment, this functionality is only achievable by querying the Slot information of IDs and then constructing the DB of Slots and IDs based on this query, or by constructing events and logs.

Conclusion

To sum up, ERC-20, ERC-721, ERC-1155, and ERC-3525 all have unique use cases, and projects should choose the most fitting token standard according to the specific demand of their tokenomics. Despite that, it should be noted that the new ERC-3525 is far more complex than all three other contracts. It not only inherits the features of the previous standards but also introduced the unique Slot data structure, which allows it to perform new tasks. In addition, although ERC-3525 offers more functionalities, it still maintains the orderliness of the records, which strikes us as a remarkable innovation. That said, considering the more diversified information and records, it is foreseeable that ERC-3525’s gas fee will be expensive, and the standard will be subject to unknown vulnerability attacks (after all, it has stood the test of time).