Overview of the repo

• Universal Token For Assets and Payments
• Certificate-based token transfers
• Delivery-vs-payment
• Fund issuance

Introduction

Never heard of tokenization

--> See introduction here.

Never hear of Universal Token for Assets and Payments

--> See webinar recording here.

--> See blog article here.

Blockchain technology and more specifically the emergence of "programmable" tokens have opened a world of new possibilities for financial assets: the creation of digital assets. Digital assets are financial assets, which have been "tokenized". This means each asset is represented by a token on the blockchain.

As introduced by the token taxonomy framework, there are 3 main categories of tokens:

• Fungible tokens: Fungible tokens are all identical and cannot be distinguished from each other. Each individual token is essentially interchangeable, like US dollars, company shares, or ounces of gold. This is probably the simplest and most common category of tokens.
• Non-fungible tokens: A non-fungible token is unique. Non-fungible tokens (NFTs) are used to create verifiable digital scarcity, as well as representing asset ownership of things like real estate, luxury goods, works of art, or collectible objects in video games (CryptoKitties is an early example). Essentially, NFTs are used for items which require a unique digital fingerprint.
• Hybrid tokens: Hybrid tokens are a mix of both. Each token belongs to a class (sometimes also called category/partition/tranche). Inside a given class, all tokens are the same: they are fungible. But tokens from different classes can be distinguished from each other: they are non-fungible. By combining both advantages of fungibility and non-fungibility, hybrid tokens often appear as a relevant way to represent financial assets.

Token standards have emerged in the Ethereum community.

ERC20 is the most basic and most adopted token standard. It can be seen as the "axiom of fungible token standards" and is compatible with the majority of existing tools and platforms.

ERC1400 is a hybrid token standard precisely designed for the use case of tokenized financial assets:

• By being ERC20 retrocompatible, it remains compatible with the majority of existing tools and platforms.
• By being partially-fungible (hybrid token), it allows to represent different classes of assets, perform more evolved token actions (lock tokens, collateralize tokens, etc.), which is essential in the context of corporate actions.
• By offering the possibility to attach data to transfers, strong control over token transfers, based on granular certificate checks can be setup by issuers.

The following repository contains the ERC1400 implementation used by the Codefi Assets platform.

Why do we need a Universal Token for Assets and Payments?

When we started developing the token, we knew that the future would sit at the intersection of traditional finance and decentralized finance. Our ambition was to find a way to create a bridge between both worlds. But as of today, those 2 have very different characteristics:

• DeCentralised finance is still reserved mainly for crypto-friendly investors, and has difficulties attracting more traditional ones
• Traditional finance still requires strong control capabilities over issued assets, while DeFi fosters more on simplicity of access and processes automation
• Finally the first one relies on trust in the law, and financial institutions, while the latter relies on trust in the code

Now the question is:

• How do we reconcile those 2 worlds?
• How do we increase the diversity and the volume of assets in the DeFi world?
• How can we release traditional assets in the DeFi economy, in order to benefit from the advantages it provides?

The future looks like this. A world where DeFi automation mechanisms are extended to traditional assets, while remaining compliant with existing regulatory constraints.

Of course this can not happen in one day, and Codefi’s mission is to make the transition painless. We want to SMOOTHLY introduce traditional investors to the world of DeFi, without ignoring requirements of the existing system.

Today, DeFi is still reserved for “early adopters”. Accepting the constraints of the existing system (strong issuer or regulator control capabilities, legal agreements, investor verification, etc.) is the only way to convince the “early majority” to adopt a new mindset.

Building upon the existing system is the only way to increase adoption.

What are the main challenges to overcome?

4 major requirements to overcome, to make the CeFi <> DeFi convergence a reality are the following:

• Adapted control mechanisms: it’s a legal requirement for asset issuers in traditional finance to be empowered with strong control capabilities over issued assets
• Permanent reliability of investor registry: asset issuers are accountable for maintaining a reliable investor registry
• Certainty of execution for delivery-vs-payment: delivery-vs-payment operations on the secondary market, need to be the result of mechanisms that can not fail
• Interoperability with the Ethereum ecosystem: all those requirements need to be taken into account while remaining compatible with the Ethereum ecosystem and more specifically with the DeFi tools

We’ll now deep dive into those 4 requirements to see what essential features a universal token for assets and payments shall offer.

Interoperability with the Ethereum ecosystem

ERC20 interface

One of the things that Ethereum has done best is its token standards. The whole Ethereum community has reached consensus on those standards. A rich ecosystem of tools and platforms has emerged. The most well-known token standard is called ERC20: it is an interface for fungible tokens.

Its “transfer” and “balanceOf” functions are now pre-requisites to be compatible with wallets and key custody solutions, like Metamask of Ledger hardware wallets.

Its “allowance” and “transferFrom” functions are important for interoperability with other smart contracts. Airswap p2p trading plaform uses those functions to execute delivery-vs-payment operations.

Possibility to escrow tokens

Another important aspect for interoperability is the possibility to escrow tokens.

Escrow a token means accepting a smart contract to be the owner of the token (instead of a human person). Token escrow mechanisms are used by lots of DeFi smart contract:

• Lending contracts like Compound need escrows to store collateralized tokens
• Decentralized exchanges like Uniswap or derivatives platforms like Synthetix need escrows to create liquidity pools

In the end, an ERC20 interface + the possibility to escrow tokens are mandatory to be compatible with the Ethereum ecosystem.

Control Mechanisms

Second major topic for assets and payments is control mechanisms.

When building financial instruments, controlling who has access to a specific instrument is paramount. Every asset distribution, or asset transfer needs to be controlled by the issuer of the asset. There are two main solution that we’ve implemented.

• Certificates generated off-chain: a certificate is a signed hash of the transaction parameters. A new certificate needs to be created for every new transfer. This offers very strong control capabilities. But unfortunately, it is not compatible with the ERC20 interface, thus making things more complex when it comes towards interoperability with the Ethereum ecosystem.
• List of validated investors stored on-chain: the token smart contract just consults this list every time it needs to perform a transfer. In the future, we can envision a world where such global allowlists will be curated by consortiums of financial institutions or even regulators themselves, but today, those don’t exist. This method lacks flexibility since an Ethereum transaction is required everytime we need to modify the list. But the good thing is, it allows to use the ERC20 transfer function, thus making it interoperable with the Ethereum ecosystem.

In traditional finance, correct maintenance of a registry is the responsibility of very large institutions, like central security depositories, transfer agent or even issuers themselves in some cases. These institutions must retain full control over the registry. When the token is configured to be “controllable”, it provides the issuer with the capability to force token transfers, token creation, or destruction.

It is not the case in DeFi, where no one but the token holder can decide to transfer a token. This is seen by some as a really powerful feature, moving trust at the core of a protocol rather than in a public or private authority.

Both setups, controllable or not, can be adapted, depending on the use case, and the “renounceControl” function allows to switch from one setup to the other.

Reliability of investor registry

When moving traditional securities on a public blockchain network, a fundamental principle needs to be respected: the created ownership registry shall at all time, reflect the beneficial