By Jeroen Offerijns, CTO @ Centrifuge
In Ethereum, token standards are predefined sets of rules and functions for tokens to follow. They allow for consistent behavior of tokens for various applications, facilitating seamless interoperability across decentralized finance.
If you’ve transacted onchain, you’ve likely benefited from a few standards already in place. ERC-20 is the most common standard for fungible tokens, like governance and utility tokens, whereas ERC-721 is the standard for non-fungible tokens, or NFTs.
These standards have become crucial for decentralized finance, acting as the backbone for many DeFi protocols — including Centrifuge. Since the launch of Centrifuge’s initial Ethereum-based pools over 4 years ago, ERC-20 tokens have been used for tranche tokens (representing an investors stake) and ERC-721 tokens to tokenize individual real-world assets.
Token Standards for Real-World Assets
We can take token standards further, developing new standards for real-world assets (RWAs). Let’s first revisit two major benefits of tokenizing RWAs onchain:
-
Programmatically tokenizing and financing assets onchain offers efficiencies and cost savings over traditional offchain processes.
-
It allows integration with the broader DeFi ecosystem. We call this composability.
Token standards power composability in decentralized finance. So far, we’ve seen amazing apps built in DeFi that take advantage of the composability inherent in ERC-20 and ERC-721 tokens. If tokens are not standardized, however, composability becomes a great challenge, as custom integrations must be made for each cross-platform connection.
The recently-implemented ERC-4626 Tokenized Vault Standard creates a standard for “tokenized vaults”: a standardized yield-bearing token. An ERC-4626 token represents your share in an investment, like a liquidity pool, and accrues value. While powerful for traditional decentralized finance protocols, there are limitations that require further development for the tokenized vault standard to be effective for real-world assets.
ERC-7540: Asynchronous Tokenized Vaults: Extending ERC-4626
In traditional ERC-4626 tokenized vaults, users deposit assets, earn yield through shares, and eventually redeem their investments. Here, the investment and redemptions happen instantly. A user deposits tokens into a pool and immediately receives tokens representing their share, or else the transaction reverts.
The process for real-world assets — in particular for Centrifuge — requires the submission of orders and then a waiting period for fulfillment. This is because investments, redemptions, asset originations, and asset repayments must be coordinated. Users deposit tokens into a pool and receive tokens representing their share until the request is complete later on.
Members of the Centrifuge team alongside Joey Santoro, author of the original ERC-4626 proposal, Vikram Arun, cofounder of the 4626 Alliance, and Farhaan Ali, smart contracts lead at Maple have proposed extending the ERC4626 standard with asynchronous deposit and redemption support. The ERC-7540 proposal innovates on the 4626 standard by adding the functionality to submit requests for investment and redemption, enhancing the efficiency of yield earning in RWAs.
In our legacy Ethereum-based pools, we’ve already built this flow and accrued nearly $250 million in total value locked over the past 3 years. Investments and redemptions are only processed when an epoch closes. We’ve written the above proposal using years of experience in designing an asynchronous investment/redemption flow for Centrifuge.
With this behavior standardized via the extended ERC-4626 standard on Ethereum per the above proposal, we can standardize this investment and redemption flow, making it more efficient and composable. Plus, a standardized implementation helps create reusable tests for more security protocols. Check out Blockwork’s article on the 7540 proposal to hear more from our team on why we’re building 7540!
Looking Into the Future: Asset and KYC Token Standards
As we look towards the future, we see two more opportunities for new token standards: asset origination and KYC processes.
Token standards for painless KYC
Permissioned DeFi (requiring KYC, or “Know your Customer”) is still in its infancy, but it will be a legal necessity as our space matures. With real-world assets, offchain legal structures necessitate this process.
But there’s currently no single, standardized solution for KYC. A token standard to link KYC information to a wallet can…
-
Check onchain whether a wallet belongs to an individual or an entity
-
Determine information about the person / entity: location, accreditation, etc
-
Track who has “signed off” on this KYC information
With a KYC token standard, not only is the user experience improved; new possibilities are unlocked for composability. For example: Centrifuge investments could be traded on secondary markets like Mauve without the user needing to perform an additional KYC check. And looking more broadly: users could KYC just once and interact with any permissioned protocol without additional onboarding steps.
Token standards for tokenized assets
Standardizing assets — i.e. moving beyond simple ERC-721 implementations — can create a standard more suited towards tokenized real-world assets. This can make standardized data for composability and for purpose-built UI; furthermore, it’s easier to plug in third party and offchain data with a standardized token for real-world assets.
We imagine credit funds operating onchain — like BlockTower — making use of new asset token standards not only to improve their tokenizing flow, but to be able to easily build new features themselves on top of Centrifuge’s platform.
The Centrifuge team has been building on Ethereum for over 4 years. Throughout, we’ve come to learn the ins and outs of building decentralized finance and the importance of efficiency, security, and composability. Token standards will make a difference not only behind the scenes — they will also create a more efficient, accessible, and user-friendly decentralized finance ecosystem.