Tokenization Of The Asset On Gen2 Blockchain
Last updated
Last updated
The difference between gen1 blockchains like Bitcoin (BTC) and gen2 blockchains like Ethereum, especially its latest iteration (commonly referred to as Ethereum 2.0 or Eth2), primarily lies in their capabilities, underlying technology, and intended use cases.
First-Generation Blockchains (e.g. Bitcoin):
Second-Generation Blockchains (e.g. Ethereum 2.0):
Single purpose: was designed primarily as a decentralized digital currency. Its main function is to enable peer-to-peer transactions without the need for a trusted third party.
PoW: It operates on a proof-of-work (PoW) consensus mechanism, where miners solve complex mathematical problems to validate transactions and create new blocks.
Functionally limited: supports the transfer of its native cryptocurrency but does not natively support complex contracts or decentralized applications (DApps).
Multi purpose: Extends beyond a digital currency to a decentralized platform that supports smart contracts and DApps. This allows for a wide range of applications, from finance to gaming, that can run autonomously on the blockchain.
PoS: In many cases gen2 blockchains are transitioning to a proof-of-stake (PoS) consensus mechanism, which is more energy-efficient than PoW and involves validators staking their native blockchain tokens to validate transactions.
Less functionally limited: Supports the creation and execution of smart contracts, which are self-executing logical clauses stored on the blockchain and triggerable by the wallets, who pay native blockchain fee to execute them.
The concept of 'asset tokenization' requires careful examination from more than one perspective, given its multifaceted nature:
Documentation in Digital Form: The act of storing data on the blockchain constitutes digital documentation within a blockchain system. This process could more accurately be termed 'blockchainization' because it involves embedding records into the blockchain's structure, rather than traditional tokenization.
Blockchain as a Reference Point, Not a Repository: When it comes to documenting asset existence, tokens typically do not store comprehensive asset details directly on the blockchain. This is due to:
Data Immutability: The risk that if the de-hashing key is compromised, it could lead to the unintended release of confidential information.
Record Permanency: Any amendment in the records necessitates the creation of a new entry, while all previous versions remain on the blockchain, leading to redundancies and potential confusion.
Legal Recognition of Blockchain Events: For more information on the legal standing of blockchain events, one should refer to the section on Causative Events.
A Mapping Exercise Rather Than Direct Recording: Tokenization often involves using blockchain-based tokens as pointers or references to asset details stored in off-chain databases. These databases are maintained by RWA service providers. This reliance on external databases can undermine the benefits of blockchain's immutability; if the external mappings are lost, the persistence of tokens on the blockchain may be rendered meaningless.
Given these complexities, the discussion on how RWA tokenization ought to be conceptualized will be set aside for the moment (as it is thoroughly discussed in the Issues and problems to be solved section. Instead, the focus will be on summarizing the current methodologies for using tokens to document both the existence and the ownership of assets.
For the present discussion, attention is directed to the 'as is' approach to tokenization, which is detailed in the chart provided below.
To encapsulate the visual summary:
The process of asset tokenization involves employing blockchain technology to represent assets as tokens, and this typically includes:
Pre-Existing Smart Contracts: These are often provided as a service, such as smart contracts designed for minting Non-Fungible Tokens (NFTs) that represent the existence and ownership details of real estate on the blockchain.
Custom-Built Smart Contracts: Entities with specific needs may opt for tailor-made smart contracts. This bespoke approach is commonly preferred by high-profile organizations that require unique tokenization features.
Smart Contract Generators: Clients can gain access to off-chain platforms that offer the ability to create their own smart contracts using templates. These templates provide a range of editable parameters and scenarios to suit different tokenization needs.
Smart contracts are then utilized to issue tokens, which can be:
Non-Fungible Tokens (NFTs): Suitable for documenting the existence and ownership of discrete, countable items. This can include singular ownership or joint ownership scenarios.
Fungible Tokens: Appropriate for representing assets that are not singular or countable, like currencies, or to denote collective ownership stakes in an asset.
Depending on the tokenization service provided, the client may also have access to an off-chain management dashboard that allows for:
Monitoring: Keeping track of the minted tokens, including ownership, transfers, and other activities.
Interaction: Executing predefined functions within their smart contract, as determined by the parameters set during the creation or customization of the smart contract.
