Tokenization

Tokenization ( Wrapped Assets ) is the process of converting physical (and non-physical) assets into digital tokens on a blockchain. The concept has grown relatively popular in the cryptocurrency space and is beginning to inch its way into traditional industries as well. Real estate, artwork, stocks – just a shortlist of the assets that companies are beginning to tokenize.

All about Tokenization ( Wrapped Assets )

Tokens have actually brought somewhat greater utility for the blockchain industry as a whole, allowing technology to be built into just about all sectors which are present.

Ethereum (ETH) is the most utilized blockchain around the globe for developers to issue tokens that are new. Specifically, there are thousands of tokens already given on Ethereum, alongside many requirements being token completely created or in progress, such as ERC-1400/ERC-1410 for security tokens. Together with this, an assortment that is broad tends to be creating security branded tokens like Polymath or Securitize.

You can find a large number of token requirements currently regarding the Ethereum blockchain and introduced as “EIPs”. These generally include numerous customizable elements such as for example fungibility standing, minting/burning features, and transfer that is possible.

Partly due to Ethereum’s scalability constraints, competing blockchains that can be programmable support their own token requirements, either natively or constructed (i.e., through the implementation of smart agreements).

A native standard describes a blockchain that natively supports the creation of particular tokens on its chain, with Binance Chain being an example that is prime. On the other hand, A built standard is really a blockchain whose tokens tend to be supported as an element of a smart- contract function, Ethereum being the essential famous example.

Various other competing that are popular include EOS, Ontology, and Tron or second levels operating on blockchains like Simple Ledger Protocol for Bitcoin Cash. This competitor takes place on different factors such as for instance when you look at the growing tokenization of possessions.

DApp availability or growing use cases: the more applications a blockchain has, the greater the value proposition is.

Transactions and pace: the more effective a blockchain is, the more appealing it usually becomes. On-chain transaction reliability also reflects the level of popularity of a network.

Blockchain fees: the low on-chain and token issuance costs tend to be, the greater the rewards to interact in the on-chain ecosystem.

Easiness to build: elements such as instance a test-net, EVM-compatibility, and smart-contract languages perform one factor that is key to attracting users.

Security and blockchain development: primary task on the blockchain, shown by how many improvement proposals or the count of developers on layer 1, security of the blockchain is very essential with vector attacks and past attacks being focal points.

(De)centralization: the degree of centralization impacts the worth idea of a sequence, especially through the point of view of potential stakeholders being token.

Especially, these above key aspects are believed by various stakeholders, such investors and token-holders, prospective and application this is certainly current, and tasks when trying to issue tokens.

Yet, “impossible trade-offs” remain, which basically originate through the blockchain triangle (in other words., scalability, protection, and decentralization cannot be achieved at the same time). As a result, crucial drivers such as on-chain metrics, level of adoption, or even the size of the creator pools remain as a few of the core factors to consider.

In the long run, an assortment this is certainly wide of blockchains will probably coexist if interoperability solutions across chains develop and prove to be safe and functional.

Since 2016, thousands of tokens have been produced on various blockchains, because of the majority that is vast on the Ethereum blockchain. The minting of brand new tokens with supplementary token criteria, this report considers and analyzes the diversity of token requirements across blockchains amidst the releases of more recent blockchains that help.

Tokenization standards on Ethereum

Ethereum ended up being the initial blockchain that is programmable designed to act as the “world computer”.

In 2013, the whitepaper for Ethereum ended up being compiled by Vitalik Buterin. It described an open-source, general public, blockchain-based distributed computing platform that could operate smart contracts: applications that operate exactly as programmed without the probability of downtime, censorship, fraud, or third-party interference.

Ethereum makes it possible for designers to construct and set up smart contracts, also as issue their very own cryptocurrency directly on the Ethereum blockchain eliminating the necessity for developers to generate their own blockchain this is certainly new to their particular service. It saves developers not merely the proper time it will take to create a blockchain but additionally makes it possible for them to leverage the safety and decentralization of Ethereum.

As a result, Ethereum has turned out to be the “go-to” blockchain standard for building utility tokens and capital this is certainly raising. Additionally, new decentralized applications such as instance DeFi applications have actually headed to network this is certainly positive, attracting almost all of the blockchain developers to create on Ethereum.

We can differentiate utility tokens from security tokens at the code level, with protection tokens referring to tokens whose integrated functions tend to be intended to make them compliant with both existing and future securities regulations. Particularly, safety token criteria introduce brand new methods for issuers, such as whitelisting of wallet details, ownership, and transfer restrictions, as well as the creation of main authorities.

Utility Tokens

Regarding utility tokens on Ethereum, probably the most criteria are common ERC-20 for fungible tokens and ERC-721 for non-fungible tokens. This subsection discusses numerous criteria being token used, in development or drafted variations.

ERC 20

ERC 20 is the most well-known Ethereum token standard and almost all ICOs (what is an ICO initial coin offering) that used the Ethereum platform have used it. Developers use it by default to create new tokens, while wallets and exchanges accept ERC 20 tokens easily.

Before ERC 20, Ethereum developers had to specifically set rules that their token will follow, and this approach lacked standardization to scale Ethereum dApps. Now with ERC20, Ethereum developers know that they will just have to use ERC 20 standard. This standardization played a big part in fueling the ICO craze we saw since 2017.

6 Fundamental Features of ERC20

The ERC 20 standard prescribes the following functions when developing an Ethereum token:

  • Get the total supply of tokens: You need to use the “totalSupply” function.
  • Retrieve another owner accounts’ token balance.
  • Send tokens to another owner account: You need to use the “transfer” function. These accounts are EOA accounts.
  • Send tokens from one token address to another. Token addresses are contract addresses, and you need to use “transferFrom” function.
  • Allow another account to withdraw funds from your account repeatedly, within a specified limit. You should use the “approve” function for this.
  • Spenders can return unused tokens to owners, using the “allowance” function.

The ERC 20 Bug That Burns Tokens!

While very well documented and implemented overall, the ERC 20 standard has a bug, and this has already burnt tokens worth millions of US dollars. The “transfer” function only allows you to send tokens to another owner, i.e., an EOA account.

If you want to send funds to a smart contract account, i.e., the other form of Ethereum accounts, you need to use “approve” and “transferFrom” combination. If you send tokens to a smart contract using the “transfer” function, you will see a successful transaction, but the contract will never receive the tokens.

This trait burns those tokens permanently, and you can’t retrieve them. Several users have used the wrong function to send tokens to smart contracts and lost their tokens for good! The Ethereum Foundation knows about the bug but continues to promote the ERC 20 standard.

The ERC223 Token Standard: A Proposed Resolution for The ERC 20 Bug

An Ethereum developer who goes by the Reddit username “Dexaran” proposed the EIP 223 with a solution to this ERC 20 bug. The ERC223 token standard is still a draft, and the Ethereum community hasn’t implemented it yet. It proposes the following solution:

It considers a transaction on the Ethereum blockchain as an event and uses the ‘event-handling’ concept. If users use the “transfer” function to send tokens to a smart contract, it will throw an error, and will subsequently cancel the transaction. The user pays the Ethereum “Gas price”, but doesn’t lose any token. This proposal adds an additional parameter to the “transfer” function, to check whether the receiving address is a contract account.

If it finds that the recipient address is a contract account and not an EOA account, then it assumes that the contract has implemented a “tokenFallback”. A “tokenFallback” function allows calling back the token, so the transaction doesn’t burn any token. While the ERC223 solves the ERC 20 bug to a great extent, there is a weakness in this proposal. If the recipient smart contract doesn’t have a “tokanFallback” function, then the “Fallback” function will run, resulting in the loss of tokens.

Only a few projects use the ERC 223, an example is the AmigoCoin project. This standard is also called the ERC 23.

The ERC777 Standard: An Improved Proposal to Resolve the ERC 20 Bug

An improved proposal to prevent the loss of tokens due to the ERC 20 bug is the ERC 777 proposal. It includes the following:

New functions: “send” instead of “transfer”, “authoriseOperator” instead of “approve”, and “tokensReceived” instead of “tokenFallback”.

So long the Ethereum platform had a drawback because developers couldn’t identify what functions smart contracts implement. ERC 820, i.e., another standard, has implemented a central registry of contracts on the network, hence it’s now possible to know the functions and interfaces a smart contract has. ERC777 uses it to identify interfaces that a smart contract uses. Now developers will know beforehand whether a contract has the functions required to receive tokens sent via certain functions.

ERC 777 enables ‘whitelisting’ of operators, so the Ethereum network users will now have the capability to reject payment from blacklisted addresses. An address can be blacklisted due to many reasons, for e.g., attempt to hack the network, history of illegal activities.

Risks of ERC777

You can see in the ERC 777 vs ERC 20 vs ERC 223 comparison how the ERC777 provides multiple options to developers so that they can prevent loss of tokens. However, the ERC777 standard also comes with a few risks, as follows:

Some Ethereum developers believe that the “authoriseOperator” function is deprecated, hence developers shouldn’t use it. This function will also require more “Gas” and it will put additional strain on the network. The use of a central registry of smart contracts to look up for the interfaces a contract uses is risky. A central registry may have bugs, and anything depends on it will have an adverse impact.

ORCA token is a great ERC777 example that is a banking platform designed for crypto users. Recently, non fungible tokens or NFTs and ERC-721 have gained much traction and people are getting more interested in non-interchangeable and unique tokens. What is the difference between ERC20 vs ERC721? ERC20 deals with money and money-like tokens while ERC721 deals with unique and non-interchangeable things.

ERC 721

ERC721 is firstly, a type of standard and a standard is simply a template or format that other developers agree to follow. Developers follow the same standards because it makes writing code easier, more predictable, and reusable. These standards are completely voluntary, but following a widely used standard   means   compatibility   with   a   wide   variety   of   applications including exchanges, dapps, and wallets.

ERC721 is a token standard on Ethereum for Non-Fungible Tokens (NFT). Fungible means interchangeable and replaceable so something like Bitcoin is fungible because any Bitcoin can replace another Bitcoin. Each NFT, on the other hand, is completely unique. One NFT cannot replace another.

ERC 998

Ever since CryptoKitties, ERC-721 has quickly become the de facto Ethereum standard for creating unique, digital assets known as non-fungible tokens (NFTs). ERC-721 tokens can represent anything from kittens to collectible baseball players. I wrote about this standard and its real-world applications in an earlier post.

ERC-998 acts as an extension of ERC-721, allowing you to “compose” a new token from a group of ERC-721 assets. Your in-game character can now be composed of all of its underlying NFTs: shield, sword, boots, special items, and even other ERC-20 tokens. When you are ready to sell or trade the character, it takes just one blockchain transaction, after which all underlying assets belong to the new owner.

ERC-1155

ERC-1155is a digital token standard created by Enjin that can used to create both fungible (currencies) and non-fungible (digital cards, pets and in-game skins) assets on the Ethereum Network. By using the Ethereum network, ERC-1155 tokens are secure, tradable and immune to hacking. To find out more about the specifications of the ERC-1155 standard, check out EIP 1155.

ERC-1155 a new way of creating tokens that allow for more efficient trades and bundling of transactions – thus saving costs. This token standard allows for the creation of both utility tokens (such as $BNB or $BAT) and also Non-Fungible Tokens like CryptoKitties.

ERC-1155 includes optimizations that allow for more efficient and safer transactions. Transactions could be bundled together – thus reducing the cost of transferring tokens. ERC- 1155 builds on previous work such as ERC-20 (utility tokens) and ERC-721 (rare one-time collectibles).

Security token

Security tokens are designed to represent “complete or fractional ownership interests in assets and/or entities”. While utility tokens have no limitation on who can send or receive the token, security tokens are subject to greater restrictions based on identity, jurisdiction, and asset category.

ERC 1400

ERC1400 was born of the need for consistency in how we build, issue, trade, and manage security tokens. ERC1400 combines new and existing standards with the goal of creating a unified framework for all security tokens. It builds off of our ST20 protocol as an extensible and flexible set of standards for:

  • Core compliance components
  • Document handling and notification
  • Security token controls and permissions including delegation and forced token transfers
  • Partial fungibility – improving transparency for investors of their ownership rights

ERC 1410

This standard sits under the ERC-1400 (#1411) umbrella set of standards related to security tokens. Describes an interface to support an owners tokens being grouped into partitions, with each partition being represented by an identifying key and a balance.

Tokens are operated upon at a partition granularity, but data about the overall supply of tokens and overall balances of owners is also tracked. This standard can be combined with ERC-20 (#20) or ERC-777 (#777) to provide an additional layer of granular transparency as to the behaviour of a token contract on different partitions of a token holders balance.

ERC-1594

Sits under the ERC-1400 umbrella set of standards related to security tokens. Provides a standard to support off-chain injection of data into transfers / issuance / redemption and the ability to check the validity of a transfer distinct from it’s execution.

ERC-1643

This standard sits under the ERC-1400 umbrella set of standards related to security tokens. Provides a standard to support attaching documentation to smart contracts, specifically security token contracts in the context of ERC-1400.

ERC-1644

Allows a token to transparently declare whether or not a controller can unilaterally transfer tokens between addresses.

ERC-1404

Tokensoft originated standard which provides restricted transfer of tokens based upon jurisdictional regulations including interjurisdictional transfers. GitHub also see erc1404.org and Medium.

ERC-884

ERC-884 token is an ERC-20 compatible token, which was developed by David Sag to comply with the Delaware General Corporate Law.

Delaware corporations can use blockchain technologies to create a tradable ERC-20 token and maintain shares issued by a Delaware corporation.

ERC-1450

StartEngine standard to extend ERC-20 to that enables issuing tokens representing securities that are required to comply with one or more of the following Securities Act Regulations: Regulation Crowdfunding, Regulation D, and Regulation A. GitHub also see EIPS.

Read more