Ecosystem Explorer — Exploring Architectural Risks in RWA Projects

1. Real-World Assets on Blockchain — Motivation

Until recently, the crypto market has been led by individuals and a few crypto VCs. This has been a bottleneck for the crypto market to grow to a larger scale because despite the huge capital size of pension funds and existing Web2 asset management companies, they have not been able to enter the market due to various risks in the crypto market. Recently emerging Real-World Assets (RWA) projects are creating an environment where real estate or real assets with less volatility than cryptocurrencies can be easily traded in a Web3 environment.

2. Types of RWA Projects

Currently, RWA-related projects can be classified as follows:

• RWA Marketplace: Marketplaces that support trading of tokenized general assets. Here, general assets refer to all forms of assets including real estate and real-world products such as gold and luxuries.
• Infrastructure: Projects that build its own blockchain ecosystem which are specialized in RWA trading or supporting specific fields of assets.
• Credit Loans: Projects that enable unsecured lending via credit history through collaboration with off-chain financial institutions, in contrast to the crypto collateral-based lending projects.
• RWA-backed Stablecoins: Stablecoins backed by RWA assets, operating RWA assets in Web2, and distributing the profits to Web3 project users.

In the sections below, we will analyze the structure of representative projects by category and discuss the potential risks they may have.

3. Case Studies & Risk Analysis

3.1. Case Study A: RWA Marketplace

3.1.1. Tangible

Tangible is a project that supports a marketplace for trading real assets wrapped as NFTs through smart contracts. They implemented a system that allows users to trade real estate, gold, wine, watches in the form of NFTs on their own marketplace, but in collaboration with Web2 brokers, users can receive the real assets when they claim them with purchased NFTs.

During the research, Tangible launched its v2 protocol on its own L2, re.al. We clarify that this report only covers the architecture of Tangible v1.

Structure

The process of trading RWA through the Tangible marketplace is as shown in the figure below.

Workflow of buying Tangible-native RWA through marketplace.

Users can find and purchase desired products on Tangible’s marketplace, and the purchased products are issued as NFTs and transferred to the user’s wallet. When an NFT is issued, Tangible Custody purchases the real asset through a partner broker and moves it to a warehouse operated by Tangible for storage. At this time, the user purchases the product through Tangible’s own stablecoin, USDR.

There is also a way for users to purchase already issued NFTs from other users, and the process is as shown in the figure below.

Workflow of trading RWA with other Tangible users through marketplace.

The user pays USDR and receives the NFT to be purchased, and the seller receives tokens converted to USDC instead of USDR. At this time, a separate fee of 2.5% is transferred to the Tangible DAO, and the transferred USDC is reused for the ecosystem.

Risks

Tangible has already experienced a severe depegging of USDR in October 2023 due to its architectural risks, and as a result, it is currently preparing to release the next version. The risks below describe Tangible’s architectural risks and how they worked in actual cases.

• Real Asset Claim Risk: Tangible’s official documentation and blog post describes claiming real assets through NFTs as if it is possible at any time, but its Terms of Service states that “Purchases of TNFT are subject to the availability of the respective Asset. Tangible does not guarantee that any particular TNFT will be available.” Therefore, users who purchase NFTs may not be able to receive the real asset corresponding to the NFT when they actually claim it.
• Web2 Broker Dependency: Tangible states that it issues NFTs corresponding to real assets and purchases and stores real assets through partner companies. However, if Tangible’s credibility declines or USDR depegs, causing user purchases to result in losses for partner companies, there is a possibility that the acquisition of real assets may be refused. When USDR depegged to around $0.5, even if gold bullion or watches were purchased on the Tangible marketplace, there is a very high possibility that the real assets were not received due to the two issues mentioned above.
• Stablecoin Risk: This can be said to be the most serious risk faced by Tangible. The biggest reason for USDR’s depegging was panic selling due to the instability of stablecoin collateral. At the time of the incident, a significant portion of USDR’s collateral consisted of the project’s own token, TNGBL, and USDR LP tokens. Since the USDR token was involved in all aspects of marketplace operation and the project’s own token TNGBL, the form in which the project is entirely dependent on its own stablecoin does not seem very desirable.

3.1.2. Swarm Markets

Swarm is a project that aims to be a decentralized RWA marketplace based on AMM, allowing trading of tokenized U.S. bonds and stocks in its own pools. The tokenization certificates for each asset are registered with the European Securities and Markets Authority (ESMA), and Swarm emphasizes that the project is compatible with EU regulations based on this.

Structure

From a technical perspective, Swarm is a very simple DEX, as it directly forks and uses Balancer’s pool contract. Swarm services this under the name dOTC, and the structure itself is no different from a typical DEX swap pool.

What sets Swarm apart from a typical DEX is the ability to trade tokenized bonds and stocks. The real-world assets supported by Swarm are as follows:

• Bonds: Tokenized versions of BlackRock iShares’ short-term bonds under 1 year (TBONDS01) and short-term bonds between 1 and 3 years (TBONDS13) are supported.
• Stocks: Tokenized versions of Apple, Tesla, Coinbase, BlackRock, Coupang, Microsoft, Microstrategy, NVIDIA, and Intel stocks are supported.

The tokenized securities issuance process in Swarm is as follows. The entire tokenization process is monitored and managed by the token trustee.

1. The stockholder transfers the shares to the custodian account owned by the token issuer.
2. The custodian confirms to the token trustee that the assets have been received in the issuer-owned account.
3. The token trustee delivers the security tokens issued by the token issuer to the wallet designated by the shareholder.

Conversely, Swarm also explains that it is possible to claim real assets through tokenized securities. The procedure is as follows:

1. The token holder claims unpaid stablecoin dividends from the dividend smart contract. Unclaimed dividends and debt services are proportionally distributed to all token holders with the same underlying asset.
2. The token holder calls the redeem function of the smart contract to request redemption of the tokenized securities.
3. The token trustee receives the redemption request through the smart contract and instructs the custodian to transfer the underlying assets to the account specified in the request.
4. The custodian transfers the underlying assets to the token holder’s account and notifies the token trustee of the transfer completion.
5. The token trustee confirms the token transfer through the smart contract and burns the corresponding security token.

One of the features of Swarm’s tokenized securities is the Safeguard Staking function. When a certain amount or more of tokenized securities are staked, the administrator rights of the token contract are delegated to a predefined guardian, and all functions except the redemption function of the token are suspended. The guardian liquidates all staked tokens and distributes the USD stablecoins generated from the liquidation to users.

Risks

The architectural risks of Swarm are as follows:

• Liquidity Risk: Swarm promotes itself as a decentralized RWA project and boasts support for stocks and bonds. However, most of the liquidity within the service is concentrated in USDC and its own token, SMT, and most tokenized securities have very little volume with only around 10 holders, nearly failing to fulfill their intended roles. (Reference: T-bonds01, T-bonds13, Apple, Tesla, Nvidia, Microsoft) To address this, the project needs to entrust a significant amount of stocks to fill the liquidity of the pools, but this process does not seem to be happening currently. It is notable that the project’s own token, SMT, is listed on CEXs such as Gate.io and MEXC.
• Real Asset Claim Risk: It takes a considerable amount of time to burn the tokenized securities purchased on Swarm and retrieve the actual shares. Swarm specifies that this process takes less than a month, but from a user’s perspective, there are significant risks in receiving physical shares a month after burning tokens purchased at a specific price.
• Operational Risk: As explained earlier, for users to issue their assets as tokenized securities, they must transfer the physical assets to Swarm’s custodian account. For operational transparency, Swarm needs to undergo periodic audits and disclose reports on the physical assets held in the custodian account, but currently, no such materials can be found.
• Centralization Risk due to Safeguard Staking: As mentioned in the liquidity risk section, each tokenized security has very low liquidity, so malicious users can forcibly trigger the Safeguard mode by issuing or purchasing tokens. In this case, there is a possibility that the user’s tokenized securities may be forcibly liquidated by the guardian. However, in Swarm’s current structure, the decision to issue tokens is entirely determined by the project, so the Safeguard Staking feature is more likely to be triggered directly by the project rather than by malicious users. Although not directly explained in the official documentation, Swarm’s Safeguard Staking may have been designed to respond to various situations that may occur in the Web2 market. For example, if the token trustee fails to fulfill its promised obligations, the project may forcibly exercise its rights or trigger the liquidation mechanism to deal with situations where the stock price of the tokenized securities plummets. However, even if it was devised with good intentions, it is a feature that requires high liquidity to play its proper role. Therefore, Swarm needs to address the liquidity risk of real asset pools and further decentralize Safeguard Staking.
• Smart Contract Risk: Since Swarm’s smart contracts are a fork of Balancer, there may not be significant risks if known vulnerabilities of Balancer have been addressed. However, inadequate management of various centralized roles can still lead to attack vectors. Swarm has a history of being exploited for $120K on January 25, 2024, due to this. During the implementation of the project’s pilot platform, a former developer implemented a role that allowed remapping of the token contract, and this role was not properly removed during the migration of the pilot platform to a new version, leading to the attack. A detailed attack scenario can be found in the team’s postmortem.

3.1.3. Polytrade

Polytrade is an RWA marketplace launched in 2021, which is earlier than the other projects. It gained attention as an early RWA project, with Sandeep from Polygon as an advisor and raising investment as well. Polytrade currently supports the trading of various assets including liquor, real assets, luxuries, artworks, and stocks, through collaborations with various projects.

Structure

Polytrade does not provide separate documentation on technical details, as the project’s structure itself is very simple. Polytrade classifies assets broadly into two categories: Discovery Assets and Secondary Assets, and assets are traded through simple marketplace contracts.

• Discovery Asset: Assets that users can already find through other marketplaces, where Polytrade acts as an intermediary. Polytrade claims to support the trading of bonds, collectible cards, NFTs, and other various assets through collaborations with projects such as Goldfinch, Courtyard.io, and Michelin. However, in the case of these assets, Polytrade is precisely mediating between other marketplaces and users, not supporting asset tokenization.
• Secondary Asset: Assets issued when users want to sell their own assets, which are directly supported by Polytrade. Polytrade supports the ERC-6960 asset standard developed in-house, allowing users to wrap their existing ERC-20, ERC-721, ERC-1155 assets to the ERC-6960 standard for sale. The ERC-6960 standard is characterized by the ability to fragment a Main Asset into multiple Sub Assets. To issue a Secondary Asset, users must determine various details such as KYC performance, the redemption process definition, and the decision on asset fragmentation, and then contact the Polytrade team for review.

Risks

Although Polytrade has a very simple architecture, it entails the following risks:

• Real Asset Claim Risk: From the perspective of asset sellers, the ERC-6960 standard is useful as it supports partial asset sales. However, this is not the case from the buyer’s perspective. Due to the limitations of ERC-6960, unless all Sub Assets are gathered, the Main Asset cannot be claimed, and redemption of real assets through tokenized securities is also impossible. Therefore, if a malicious user purchases a small amount of a fragmentable Secondary Asset and does not put it back on the market, the value of the asset as a real object is essentially nullified. As a result, users must be aware that when purchasing fragmented assets, it may not be possible to claim the real object.

*The author believes that an RWA project should ensure that the purchase of fragmented assets can lead to the claiming of fragmented assets, guaranteeing the right to claim the real asset.

• Regulatory Risk: Polytrade primarily acts as an intermediary for assets from other RWA projects and does not directly take custody of assets, so it does not require procedures such as due diligence on assets. However, in the case of Secondary Assets directly registered by users, there is a possibility that assets subject to secondary sale regulations, depending on the country, may be listed based on the team’s review. The team will need to make considerable efforts to conduct listing reviews for Secondary Assets to manage these risks.
• Centralization Risk: Like many RWA projects, Polytrade also has a somewhat centralized structure. The flowchart below, provided by Polytrade, describes the process of onboarding user assets onto Polytrade. It can be seen that in most cases, a review by the team is required.

Onboarding Process of Polytrade. (Source)

3.2. Case Study B: Infrastructure

3.2.1. Story Protocol

Story Protocol is an infrastructure layer that tokenizes and manages copyrights. On Story Protocol, copyrights are wrapped into NFTs, and by linking user accounts to NFT-wrapped copyrights, users can exercise and manage various rights related to copyrights. The purpose of Story Protocol can be seen as processing access rights management for specific works and derivative works, as well as profit distribution for their use, in a verifiable and automated manner through smart contracts.

Structure

Architecture of Story Protocol. (Source)

The components of Story Protocol are largely divided as follows:

• IPAsset: Copyrights that are wrapped into NFTs. IPAsset is linked with an ERC-6551 based smart account called IPAccount, and users who own an IPAsset can exercise various rights assigned to the IPAsset through the smart account.
• Module: Contracts that manage the rights of IPAssets within Story Protocol. Basically, there are licensing, royalty, and dispute modules, which manage the legal licenses of IPAssets, distribute royalties, and handle copyright-related dispute elements. In addition, it supports various modules created by users, and modules designed individually for specific purposes are classified as hooks.
• Registry: Stores global state values for IPAssets and licenses. There are IPAsset, module, and license registries, which are responsible for deploying IPAccounts, managing the entire list of modules, and storing license-related state values, respectively.
• Access Controller: Manages access rights to the module contract functions of IPAccounts. Access rights to all IPAccount modules are recorded in the Permission Table and managed at the function level.

Modules

Modules are the most core component of Story Protocol. Modules can be developed by users, but the licensing, royalty, and dispute modules provided by Story Protocol are very important components that form the foundation of the protocol.

First, the licensing module stores licenses in the form of templates called “licensing templates”, which can be said to be storing commonly seen licenses, such as MIT License and BSL License in Web2, in the form of structures so that contracts can use them. Here, additional information about the offline legal contract related to the license and its stakeholders should also be provided in the form of a URL. The combination of details about the license designated using the license template is called “license terms”, and each license terms has a unique ID and can be reused among IPAssets. This is to make it easy to attach the same copyright provisions to the same type of IPAsset. In addition, the licensing module is responsible for registering a list of derivative works derived from a specific work.

The royalty module can simply be said to designate a revenue distribution model. In the existing Web2, it was difficult to track the revenue of derivative works and distribute it to the original authors, but Story Protocol allows tracking the relationship between the original work and derivative works in a tree structure and distributing profits.

The dispute module is a module created to resolve disputes related to copyrights. The dispute resolution rules, processes, and participating entities are specified in the module, and licenses in dispute can no longer be used within the protocol. Story Protocol supports permissionless disputal, and the results of disputes are tagged on the IPAsset. Here, tags assigned to the original work are inherited by derivative works.

Risks

The structural risks of Story Protocol are as follows:

Centralization risk: Currently, various elements of Story Protocol are managed by the Story Protocol team, and among them, there are elements that can place a significant burden on the team.

• Each module of Story Protocol can be created and used by users, but the safety and compliance of modules must go through the team’s review. If the complexity of user-implemented modules is high, the team’s workload can increase significantly, and if module submissions are received permissionlessly, it is unclear whether quality control will be realistically possible. License Templates also allow users to create and use them after receiving team review, sharing the same problem.
• Story Protocol’s dispute process is conducted entirely by the team. Licenses in dispute are restricted from being used within the protocol, but since opening a dispute is permissionless, a DoS-like attack is possible if multiple malicious users arbitrarily initiate the dispute process. In particular, there is a high possibility that various products like media programs will be used as derivative works through Story Protocol, and it can have a serious impact on the usability of the service if users are unable to use them in the middle.

Regulatory risk: Currently, Story Protocol has no legal means to enforce copyright infringement. There are efforts to manage these elements through off-chain by providing legal contracts related to License Templates in the form of URLs, but disputes over copyrights and their revenue can hardly have the same meaning as in Web2 unless legal entities in each country are onboarded to Story Protocol. It is also a limitation that even if an IPAsset is registered with Story Protocol, there is no way to impose any restrictions if the copyright is plagiarized and used outside the protocol.

Handling Equity Relationships: Because a copyright is wrapped as a single NFT and permissions are assigned, separate measures are necessary if equity relationships are set for a specific copyright.

3.2.2. Polymesh

Polymesh is a Substrate-based layer 1 blockchain inspired by the ERC-1400 tokenized securities standard. They aim to be a user privacy-preserving RWA chain based on decentralized identity (DID).

Structure

Polymesh is a chain developed using the Substrate framework, and it uses the GRANDPA-BABE PBFT consensus mechanism provided by Substrate. Polymesh explains that it uses a Nominated Proof-of-Stake mechanism, which means that only pre-approved entities can participate in validating. Polymesh emphasizes the stability of the network by pointing out that it can upgrade the chain without forks through the forkless runtime upgrade feature provided by the Substrate framework.

All users of Polymesh must go through a customer due diligence (CDD) process, which is very similar to the general KYC process of other projects. For this purpose, CDD providers such as Fractal, Netki, and Jumio are onboarded, and a DID is issued for users based on the CDD. In addition, for regulatory compliance, each security token issuer can perform a separate KYC process for users.

The issuance and trading of assets in Polymesh follow these procedures:

• Asset Origination: Uniquely, Polymesh does not allow duplicate tickers for security tokens, and it is implemented so that users can reserve a specific ticker for 60 days. In addition to this, the issuer mints the token, including the asset type, documentation, and requirements for compliance.
• Settlement: In Polymesh, settlement is performed in units called Instructions, which are composed of individual actions called Legs. Each Leg must receive Affirmation from all relevant accounts, and only when all Legs receive Affirmation can the Instruction be executed. Instructions that are ready to be executed can be executed by any account, and Instructions are executed atomically.

Risks

• Centralized Governance: In Polymesh, governance has very strong authority, designating node operators, CDD providers, and chain upgrades through governance. It is explained that governance proposals can be submitted by holders of Polymesh’s native token PolyX, the Technical Committee, and the Upgrade Committee. However, looking at the actual submitted governance proposals, more than 97% of the proposals were submitted by the Technical Committee and are private proposals that do not receive community voting. Given that Polymesh’s governance has very important powers in the system, there seems to be a need to sufficiently decentralize governance.
• Regulatory Risk: Polymesh has token issuers specify compliance matters through token issuance templates and automatically prevents users who do not comply from participating in the trading of security tokens. However, this approach places a significant regulatory risk on the token issuer rather than the platform, which is not suitable for the purpose of an RWA protocol aimed at easy asset accessibility. In addition, users who trade security tokens issued with incorrectly specified regulatory templates may also unintentionally bear regulatory risk.
• Usability Issues: In Polymesh, security token tickers cannot be duplicated, and users can reserve a specific ticker for 60 days. Since the length of the ticker is limited to 12 characters and no assets are consumed for the registration of security tokens itself, any group of users can occupy meaningful tickers or occupy meaningful tickers to cause user confusion. Moreover, since unanimous approval of stakeholders is required at the Settlement stage, malicious stakeholders may intentionally delay or refuse approval of Legs that do not align with their interests.

3.2.3. Plume Network

Plume Network is a separate layer 2 blockchain designed to facilitate the trading of tokenized assets. They support various elements to maximize compatibility with existing Web2 regulations.

• Restriction of supported token standards: The types of asset tokenization standards supported within the Plume Network are limited to some ERC tokens. Currently, the token standards supported by Plume Network are only four: ERC-20, ERC-721, ERC-1155, and ERC-3643. Among them, ERC-3643 is a regulation-friendly token standard that allows token issuers to add compliance rules and implements an Agent that can force transfers of tokens.
• KYC optimization: Ethereum Attestation Service is included as a precompile contract to reduce gas costs for applications that go through identity verification. In addition, they are trying to make it easy for RWA market users to verify their identities by onboarding Web2 KYC providers such as Persona to the chain.
• Anti-Money Laundering: To comply with regulators, the network itself monitors transactions and has onboarded transaction monitoring providers such as Chainalysis to the chain ecosystem. Plume Network explicitly states compliance with Office of Foreign Assets Control (OFAC) in its official documentation.

Structure

The Plume Network chain itself is a fork of Arbitrum Nitro, and the basic structure of the chain can be said to be almost the same. The differences from the existing structure are as follows:

• Gas optimization for operations frequently used in RWA interactions
• Authentication system through Ethereum Attestation Service

In summary, Plume Network can be said to be similar to Arbitrum with various service providers onboarded to the ecosystem for RWA regulatory compatibility.

Risks

The structural risks of Plume Network are as follows:

• Centralization risk: As mentioned above, the structure of Plume Network is virtually identical to that of Arbitrum Nitro. Therefore, it inherits all the existing sequencer-related centralization issues, and the team states that they plan to decentralize the sequencer in the future through Espresso, and so on. However, in addition to the sequencer, Arbitrum has somewhat centralized entities selected to verify the integrity of the chain, such as Validators and the Security Council. Since Plume Network must also select and use the same entities for fault proofs and the other functionalities, users of Plume Network must use Plume Network based on virtually the same level of trust as Offchain Labs.
• Security risk: Since it is forked from Arbitrum Nitro, there are not many issues that can arise at the chain level. While Plume Network is promptly following the updates of arbOS, compatibility issues may arise if Plume Network implements additional features in the VM in the future or does not quickly support updates to Arbitrum Nitro. This also inherits the risks of Arbitrum Nitro as the same issues arise when Arbitrum does not keep up to date with the latest Ethereum upgrades. Meanwhile, Plume Network is currently on arbOS version 20, including full support for the Ethereum Cancun upgrade and Solidity compiler v0.8.25.
• Regulatory risk: Based on the official documentation, Plume Network appears to be taking US regulators’ regulations as the standard and responding to them. If RWA projects operating in countries other than the US are onboarded to the network, it is necessary to specify whether it is possible to implement them in a way that is compatible with different regulations in each operating country, and how to resolve conflicting regulations depending on the service operating country.

3.3. Case Study C: Credit Loans

3.3.1. Creditcoin

Creditcoin is a Substrate-based layer 1 blockchain that emphasizes its role as an infrastructure layer that mediates between investors and fundraisers based on the credit history of fundraisers.

Structure

The way Creditcoin mediates investment is relatively simple, and its structure is as shown in the diagram below.

Architecture of Creditcoin. (Source)

The fundraiser places an order on Creditcoin, specifying the amount of tokens they want to borrow, the interest rate, and the repayment deadline. The investor, upon seeing the order, checks the fundraiser’s previous repayment records such as credit history, and sends an investment offer tailored to their conditions. If the fundraiser accepts, the loan funds are transferred, and the entire loan process is completed. This is not significantly different from the bid-offer structure that occurs in existing NFT marketplaces. Typically, the investor is a Fintech Lender onboarded to Creditcoin, and the fundraiser is an individual.

Since the loan records are generated on-chain, the fundraiser can perform repayment without the involvement of the investor and can adjust the loan balance or make partial repayments on the loan through negotiations with the investor. In the latter case, the investor is required to notify the network that it is a partial repayment. The investor can also sell the loan receivables, in which case the receivables purchaser repays the existing loan and takes over the claim. In this case, a relatively high interest yield can be expected under the premise that the fundraiser fully repays the loan.

The native token of the Creditcoin chain, CTC, is used only for purposes such as network validator rewards and user transaction fees but has a unique structure. CTC is divided into mainnet tokens and ERC-20 tokens.

• Mainnet CTC: Used for transaction fees and staking rewards, with the main purpose of being used by financial institutions and RWA fintech companies to record on the Creditcoin network.
• ERC-20 CTC: CTC listed on various exchanges, with no special purpose other than trading. ERC-20 CTC can be converted to mainnet CTC at a 1:1 ratio, but the reverse is not possible, implemented as a one-way swap.

The structure of issuing tokens separately for CEX listing and swapping them with native tokens implies the existence of technical/financial issues that may arise during the process of exchange support for the project’s own network.

Risks

• Initial Liquidity Risk: From the investor’s perspective, the only means to assess the creditworthiness of the fundraiser is the credit history recorded on-chain. In the early ecosystem where loans do not occur, investors have to bear a lot of credit risk.
• Investor-Fundraiser Collusion Risk: There is a scenario where the investor and fundraiser collude to build a trustworthy credit history and then borrow from other investors without repaying. In this case, it may lead to a domino effect where the harmed investor sells the fraudulent receivables to exit.
• Centralized Token Bridge: Through the token swap guide on the blog and the code disclosed on GitHub, it was confirmed that Creditcoin’s bridge is indeed centralized. The bridge is implemented in a way that a centralized entity periodically runs a script to capture events occurring on Ethereum and processes the events by sending mainnet CTC from a team-owned wallet.

3.3.2. Goldfinch

Goldfinch is a decentralized credit protocol that provides loans based on credit without cryptocurrency collateral. Borrowers can obtain stablecoin loans through Goldfinch based on off-chain collateral, and investors can participate in the loans through the senior pool and junior tranches.

Structure

The main participants in Goldfinch are Borrowers, Backers, Liquidity Providers, and Auditors.

• Borrowers: Primarily small and medium-sized lending institutions in emerging markets. They create Borrower Pools to request funds.
• Backers: Evaluate Borrower Pools, provide funds to the junior tranche, and seek relatively high risk/high return.
• Liquidity Providers: Participate in the senior pool, which automatically distributes funds to Borrower Pools, and can expect stable returns in exchange for subordinated losses.
• Auditors: Perform identity verification of Borrowers and receive rewards.

The figure below describes the architecture of Goldfinch protocol.

Architecture of Goldfinch Protocol. (Source)

Borrower Pools have junior and senior tranches. Backers receive NFTs and supply to the junior tranche, while the senior pool provides funds to the senior tranche. When the Borrower repays, the principal and interest are first distributed to the senior tranche, followed by the junior tranche. This differentiated risk-reward structure is designed to encourage active screening by Backers.

Liquidity Providers receive $FIDU tokens when participating in the senior pool. $FIDU reflects the net asset value of the senior pool and increases in value as repayments are made. Liquidity providers can redeem their $FIDU at any time for $USDC based on the NAV of the senior pool, subject to a 0.5% fee.

Backers are incentivized to supply to Borrower Pools with relatively high interest rates and $GFI rewards for early participation. In the future, Backers will be able to stake $GFI to other sponsors and receive a share of the interest income from the Borrower Pools in which those sponsors participate.

Auditors stake $GFI and are randomly selected to verify the identity of borrowers. Auditors make decisions by majority vote with other auditors, and their stake is reduced if they disagree. If 6 or more approve and 1 or fewer oppose, full approval is granted. If 6 or more approve or are uncertain, and 1 or fewer oppose, Backer-only approval is granted. In other cases, approval is denied.

Goldfinch uses “trust through consensus” as its trust mechanism. The higher the leverage ratio of the senior pool as more Backers participate in a Borrower Pool, the more collective intelligence of Backers is utilized to manage credit risk.

To prevent fraud, Goldfinch has various mechanisms in place:

• Malicious Borrowers must pass screening by Auditors and Backers, and can be sanctioned through Backers’ off-chain legal contracts.
• For malicious Backers, Sybil attacks are prevented through unique identity verification, and Backers must bear the risk of actual fund loss for malicious behavior.
• For malicious Auditors, measures such as GFI stake reduction, random selection, and repeated voting are in place.

In case of Borrower default, it is handled according to predefined procedures. After a certain period of delinquency, it is considered a default, and thereafter the senior pool investment is written down over 120 days. During this period, investors can provide bailout financing in consultation with the Borrower. If repayment is still not made, legal claims can be exercised on the off-chain collateral assets.

Risks

Goldfinch appears to manage risks relatively well through legal sanctions and the operation of Auditors. The structural risks of Goldfinch and the project’s response measures are as follows:

• Credit Risk: As Goldfinch provides credit-based loans without cryptocurrency collateral, there is an inherent risk of borrower default. Especially in the early stages of the protocol, there is a lack of on-chain data to assess borrowers’ creditworthiness, resulting in higher risk. However, rigorous screening, legally binding off-chain collateral arrangements, and utilization of existing credit assessment models are used to mitigate risk. As described, Goldfinch implemented various mechanisms to handle frauds of each participant.
• Collateral Risk: The repayment ability of Borrowers heavily relies on off-chain collateral assets. If the collateral value declines or lacks legal enforceability, borrowers may intentionally default, leading to investor losses. This can be partially mitigated by Backers’ due diligence and monitoring.
• Economic Risk: If the allocation of senior pool funds becomes overly dependent on a small number of sponsors, the decisions of particular sponsors could negatively impact all investors. Also, rising leverage ratios in the senior pool can improve profitability but also increase risk.
• Liquidity Risk: If redemption requests for $ FIDU surge, the senior pool’s liquidity may be depleted, causing temporary losses. Maintaining a certain level of cash reserves, establishing liquidation mechanisms, and designing liquidity provider incentives for extreme situations are necessary to prepare for this risk.

3.4. Case Study D: RWA-backed Stablecoins

3.4.1. Ondo Finance

Ondo Finance is a project that provides tokenized securities in the form of stablecoins backed by US Treasuries, deposits, etc. It is currently evaluated as the project designed to be most suitable for regulations, and it is carefully preparing for various risks that RWA-backed stablecoins may have.

Ondo Finance currently has two products:

1) USDY

USDY is a product that allows investment by all users who have completed KYC verification and are not citizens of the UK/US, and it is an exempt financial product under US securities law. It is a product consisting of 65% bank deposits and 35% short-term US Treasuries, and as of May 2024, it offers an interest rate of about 5%. USDY also supports a separate rebase version called rUSDY.

Structurally, USDY operates within the framework of Ondo USDY LLC, a bankruptcy-remote special purpose company and a subsidiary of Ondo Finance Inc., a Delaware corporation. Ondo has raised funds from influential investors such as Founders Fund and Coinbase Ventures, giving it the capacity to actively respond to US financial regulations.

USDY’s target asset allocation is 65% bank deposits and 35% short-term US Treasuries, and it provides 3% over-collateralization. Treasuries are held in accounts at Morgan Stanley and StoneX, and deposits are held at Morgan Stanley and First Citizens Bank.

Risks

Ondo Finance responds to the risks that may arise for USDY as follows:

• Regulatory risk: It is taking all possible measures to comply with US regulations, such as mandatory KYC through Persona and AML response through collaboration with Chainalysis. For USDY issuance, it has a review period of 40–50 days and provides a token issuance certificate in PDF format.
• Collateral risk: USDY’s collateral assets, bank deposits, are diversified and deposited in large G-SIB banks and high-quality regional banks, and Treasuries are mainly composed of short-term securities with good marketability. This minimizes the risk of a decline in the value of real assets or lack of liquidity.
• Operational risk: Ondo has outsourced asset management to Ankura Trust to ensure independence. It also conducts daily asset proofs through NAV Consulting and annual audits to enhance the reliability of real asset valuation.
• Centralization risk: Currently, Ondo Finance’s management holds key decision-making rights such as USDY minting/redemption. However, it is making efforts to disperse this by establishing separate legal entities and diversifying asset custody institutions.

2) OUSG

OUSG is a short-term US Treasury fund offered only to accredited investors worldwide who have completed KYC verification. It invests in the iShares Short-Term Treasury ETF (SHV). It currently charges a management fee of 0.3% and automatically reinvests dividends earned from the basic position. OUSG is held in ETF form in Clear Street’s brokerage account and issued as tokens on the Ethereum blockchain through Coinbase Custody.

Risks

Ondo Finance responds to the risks that may arise for OUSG as follows:

• Regulatory risk: It conducts strict KYC/AML/CFT screening of investors and requires accredited investor and qualified investor status. It prevents the possibility of regulatory violations by allowing OUSG transfers only to whitelisted addresses through smart contracts.
• Collateral risk: OUSG invests in iShares SHV, a short-term Treasury ETF with abundant market liquidity, minimizing the volatility and liquidity risk of the underlying assets. SHV manages total assets of $23.4 billion and has an average daily trading volume of over $300 million.
• Operational risk: OUSG issuance and redemption are handled by Ondo’s management team through NAV Consulting’s accounting services. It also enhances the transparency and reliability of asset management through daily asset proofs by NAV Consulting and annual external audits.
• Centralization risk: The operation of OUSG is highly dependent on Ondo Finance’s management, and investor funds are deposited in centralized institutions such as Clear Street, posing centralization risks. However, it is making efforts to mitigate this by selecting The Securities Investor Protection Corporation (SIPC) member firms and diversifying assets.

As such, Ondo Finance effectively controls asset risks through minimizing liquidity risk and transparent asset management. Nevertheless, the centralization of fund management and limited liquidity remain as potential risk factors. For deeper analysis on Ondo Finance, you can take a look at the articles from FourPillars and LlamaRisk.

4. Common Risks of RWA

While RWA projects aim to onboard existing institutions into web3, there are still various risks associated with converting web2 assets to be traded in web3, and the types are as follows:

Economic Risks

• Valuation of real assets: There are practical difficulties in receiving real-time valuation of real assets located on the Web2 side. For this reason, even for the same type of collateral, separate markets are often formed within Web3, or only futures are supported instead of the actual assets, in which case there is a high possibility of a gap between the Web2 and Web3 markets.
• Claim of real assets: When operating RWA projects targeting the general public, issues such as delivery addresses, similar to those in Web2, arise when users want to claim real assets with tokenized assets. If the claim of real assets is not guaranteed, the nature of such projects is closer to futures trading for real assets rather than trading as tokenized assets, which can lead to various regulatory risks.
• Collateral risk: When real assets are used as collateral for stablecoins, the liquidity of real assets is significantly lower than other tokens. In this case, if the value of real assets drops sharply due to external events, it is impossible to respond quickly, which can lead to severe depegging. For this reason, RWA projects currently tend to adopt assets such as gold as their main collateral rather than assets with low liquidity, such as real estate.

Regulatory Risks

Even in Web2, real assets are traded under various regulatory sandboxes for reasons such as asset valuation, insurance for asset loss/damage, and operational risks. In the case of RWA, the intention to trade by tokenizing the right to claim a specific asset on the blockchain is too clear, so there is a high possibility that Web2 regulations will be directly applied. In this case, different regulatory scopes for each country must be accommodated, and the KYC process for users is essential. However, KYC in Web3 is often not done in a completely secure way, and as a result, the trading of certain assets in Web3 may be prohibited altogether by regulatory authorities. In response, some RWA projects, such as Parcl, are blocking service access from US IPs, which are subject to relatively strict regulations.

Operational Risks

For valuation or the existence of real assets, Web2 audits must be used to resolve the issue, which is costly and there are not many users who can point out if evaluations are received through unreliable companies. Therefore, unless it is operated by large projects with known identities that can bear legal risks, users bear many operational risks. Currently, the projects that handle real assets are not providing sufficient and periodic audit reports for the transparency, except Ondo Finance.

In conclusion, RWA projects have the burden of onboarding various Web2 institutions and capital to mitigate various risks, and must defend against money laundering risks through thorough KYC. In this process, we can see cases where decentralization is somewhat compromised, and it seems that it will be a long-term consideration for all of us on how to operate a decentralized RWA project.

Security Risks

While the smart contracts of RWA projects are relatively more simple than the other Web3 projects, their centralized features embed risks that would significantly harm the project when being exploited. Since several authorized roles are implemented for various participants of RWA projects, appropriate handling of those roles and access control are much more important than the other projects. Since those roles are commonly controlled by Web2 APIs and some cases that had them exploited exist, projects should get their Web2 and Web3 features thoroughly audited.

5. Conclusion

As can be seen through the case studies in the main text, the role of smart contracts in RWA projects is not complex. This is because most of the elements are centralized for regulatory compliance. Users should be aware that RWA projects are more centralized than other projects and be cautious about this.

The most important thing in RWA projects can be said to be the economic design, and in the end, what can make the economic design work well is transparent collateral asset operation and sufficient capital to maintain the economic structure of the project. Recently, large asset management companies such as BlackRock are attempting to onboard the RWA market, which is noteworthy.

Writer’s Comment

Starting the research, I expected RWA to be somewhat centralized, but most of the projects were much more centralized than my expectation, leaving several questions.

* If a certain level of centralization is inevitable, why should RWA projects be done in Web3 in the first place? Trading RWA without legal protections entails too much risk.

* Do retail traders actually “desire” exposures to such real-world assets? I believe index-based perpetuals, such as Parcl, would rather avoid redemption / transparency issues while being more decentralized.

— c4lvin, Research Analyst at ChainLight

Reference

• https://www.tangible.store/
• https://docs.tangible.store/
• https://docs.swarmx.net/
• https://docs.swarm.com/
• https://polytrademarketplace.gitbook.io/onboarding
• https://docs.storyprotocol.xyz/
• https://x.com/StoryProtocol
• https://polymesh.network/blog
• https://developers.polymesh.network/docs/
• https://docsend.com/view/2zwzxde
• https://www.plumenetwork.xyz/blog
• https://docs.plumenetwork.xyz/plume
• https://docs.creditcoin.org/
• https://docs.goldfinch.finance/
• https://ondo.finance/usdy
• https://ondo.finance/ousg
• https://docs.ondo.finance/
• https://4pillars.io/en/articles/ondo-finance/public
• https://cryptorisks.substack.com/p/asset-overview-us-dollar-token-usdy?utm_source=publication-search

About ChainLight

Ecosystem Explorer is ChainLight’s report introducing internal analysis on trending projects of web3 ecosystem in a security perspective, written by our research analysts. With the mission to assist security researchers and developers in collectively learning, growing, and contributing to making Web3 a safer place, we release our report periodically, free of charge.

To receive the latest research and reports conducted by award-winning experts:

👉 Subscribe to our newsletter

👉 Follow @ChainLight_io

Established in 2016, ChainLight’s award-winning experts provide tailored security solutions to fortify your smart contract and help you thrive on the blockchain.