Understanding the Universal Token for Assets and Payments
When the Codefi team started developing the Universal Token for Assets and Payments, we knew that the future of finance 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, these two worlds have very different characteristics:
Decentralized finance (DeFi) is still largely reserved for crypto-friendly investors, and is undergoing difficulties attracting more traditional investment players.
Traditional finance still requires strong control capabilities over issued assets, while DeFi fosters simplicity of access and process automation.
Finally, centralized finance (CeFi) relies on trust in the law, and financial institutions, while DeFi relies on trust in code.
Now the questions are:
How do we reconcile these two worlds?
How do we increase the diversity and 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 will not happen overnight. To accomplish Codefi’s mission to make this transition painless, we want to smoothly introduce traditional investors to the world of DeFi, while carefully considering requirements of existing systems.
Accepting the constraints of the existing system (including 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.
In order to convince the early majority, our strategy is to abstract the complexity of blockchain (including Ethereum addresses, transaction asynchronism, gas payments, private key custody, etc.). If we are successful, these changes should be invisible for end-users.
Building upon the existing system is the only way to increase adoption.
What is expected from a token standard to make this convergence a reality?
What are the main challenges to overcome?
We believe there are four major requirements:
First: Adapted control mechanisms. It’s a legal requirement for asset issuers in traditional finance to be empowered with strong control capabilities over issued assets.
Second: Asset issuers are accountable for maintaining a reliable investor registry.
Third: Delivery-vs-payment operations on the secondary market, need to be the result of mechanisms that cannot fail.
Finally, all these requirements need to be taken into account while retaining compatibility with the Ethereum ecosystem, and more specifically, with DeFi tools.
We’ll now deep dive into these four requirements to explore the essential features offered by the Universal Token for Assets and Payments.
Let’s start with interoperability.
One of the things that Ethereum has done best is its token standards.
The whole Ethereum community has reached a consensus on these 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.
It’s “transfer” and “balanceOf” functions are now prerequisites to be compatible with wallets and key custody solutions, like MetaMask or Ledger hardware wallets.
Its “allowance” and “transferFrom” functions are important for interoperability with other smart contracts. For example, AirSwap’s p2p trading platform uses these functions to execute delivery-vs-payment operations.
Finally, an important aspect of interoperability is the possibility to escrow tokens. To 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 many DeFi smart contracts:
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 and the possibility to escrow tokens are mandatory for Ethereum ecosystem compatibility.
The 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 solutions that we’ve implemented to ensure this:
The one on the left is based on certificates generated off-chain. A certificate is a signed hash of 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 to interoperability with the Ethereum ecosystem.
The second solution, on the right, is based on a list of validated investors stored on-chain. The token smart contract consults this list every time it needs to perform a transfer. In the future, we envision a world where such global allow lists 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 every time the list needs to be modified. But the good thing is, it allows the use of 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 agents 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.
This 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 to the core of a protocol rather than leaving it with a public or private authority.
Both setups, controllable or not, can be adapted, depending on the use case, and the “renounceControl” function allows users to switch from one setup to the other.
Let’s move to the next topic: The reliability of the investor registry.
When moving traditional securities on a public blockchain network, a fundamental principle needs to be respected: the created ownership registry must at all times, reflect the beneficial holder of the assets.
The problem occurs when this requirement is not compatible with the escrow mechanism.
Indeed, on the right of this slide, when Joe escrow’s 4 token in an escrow contract, the owner of the token is the escrow, as visible on the blockchain is the smart-contract and not Joe.
This issue makes it complicated, or even sometimes impossible to know, that Joe is still the beneficial owner of the assets. We lose the one essential feature of the blockchain as a registry maintenance tool.
Initially, the reason why we need to send tokens to an escrow, is to lock them up and make sure they can’t be spent.
Token holds, that you can see on the left, are an alternative to escrows, allowing the lockup of tokens while keeping them in the wallet of the investor. The benefit of token holds is that they preserve the investor registry, and ensure we know who the beneficial owner of the asset is at all times.
Token holds are also very useful when it comes to distributing dividends to investors, in proportion to the amount of token they own, because we’re sure the investor registry is reliable.
Finally the last focus we’ll have is the secondary market, and the certainty of execution for delivery-vs-payment (DvP) operations.
DvP is an operation that consists of exchanging tokens representing cash against tokens representing assets.
DvP is an essential feature of the current financial system and is at the core of all financial transactions. DvP on blockchain is very interesting, as this new technology allows the execution of these operations without middlemen and with the certainty of execution.
In today’s DeFi, most DvP processes either rely on allowances or escrows in order to manage token exchanges. But both allowances and escrows are not optimal:
Allowance mechanisms (center) don’t provide certainty of execution for DvP (since the allowance doesn’t prevent the user for spending his tokens for something else after he has created a trade order)
Escrow mechanisms (right), provide certainty of execution, but as described in the previous slide, escrows do not preserve the accuracy of the registry (since the escrow contract becomes the owner of the tokens, instead of the investor).
Since allowances and escrows are not optimal, we’ve decided to use holds.
A hold, similar to an allowance, is an authorization created by the token holder, to allow someone else to transfer his tokens on his behalf. But a hold goes further than an allowance, by forbidding the holder to spend the tokens for something else, once the hold is created. The tokens are locked in his own account.
Delivery-vs-payment based on token holds (left) combines both:
The advantage of the escrow, that tokens can not be spent for something else before the trade execution
The advantage of the allowance, that preserves a reliable token registry
Moreover, token holds are compatible with HTLC mechanisms, a mechanism that allows the management of cases where atomic DvP cannot be performed:
Either when the cash token and asset tokens are on 2 different blockchain networks
Or when the cash token and asset tokens are private smart contracts (privacy groups, or zkAssets)
Now that we have all these requirements in mind, here’s an overview of the Universal Token for Assets and Payments.
As a hybrid token, it benefits from both:
The advantages of fungibility
The advantages of non-fungibility
It combines all the requirements listed in this presentation:
For control mechanisms, it offers a module for certificate checks, a module for allowlist checks, it offers the possibility to force transfers
For reliability of the investor registry, it provides a module to create token holds
For certainty of delivery-vs-payment execution, it includes token holds for atomic DvP, and HTLC mechanisms for non-atomic DVPs
For interoperability, it offers an ERC20 interface
Each of these features can be turned ON and OFF during the token’s life cycle.
We believe this modular approach offers enough flexibility to satisfy both traditional stakeholders and crypto-friendly publics, in order to make the DeFi <> CeFi convergence a reality.
The hybrid structure of the token even allows the setup of different modules for different token classes:
some classes can be setup for traditional finance, by being controllable, and including the certificate module
other classes can be setup for decentralized finance, and rely on an allowlist module
Tokens can switch from one token class to another, with an on-ramp/off-ramp mechanism. Moving tokens from one class to another allows issuers to easily change how they are controlled.
This means that issuers can issue financial instruments right now with a setup adapted to the current regulatory context, and decide to gradually adapt a setup for Decentralized Finance when the regulation becomes clearer.
In conclusion, universal token is modular, evolutive, and can be adapted to multiple use cases, thus making it a relevant standard to achieve the unification of two worlds.
The possibility to turn features on and off at any time, allows issuers to transition from CeFi to DeFi with the same token.
The evolution of the law will allow traditional finance to slowly migrate towards more “decentralized” setups
On the other hand, DeFi tools interfaces will evolve to become compatible with a higher number of standards (by supporting token holds, certificates, etc.)