Pharos Ecosystem Security Guide: End-to-End Risk Control for RWA Asset Integration

This article aims to provide developers in the Pharos ecosystem with a more practical and in-depth reference for RWA integration. We attempt to reconstruct the complex challenges and solutions faced when putting real-world assets (RWAs) on-chain from the perspectives of business logic and risk control architecture.

introduction

The Pharos ecosystem aims to become the infrastructure connecting traditional financial assets with the Web3 world. Unlike native crypto assets, Real-World Assets (RWAs) possess both off-chain physical rights and on-chain transaction attributes . This dual nature dictates that their security boundaries cannot remain solely at the smart contract level, but must extend to every aspect of asset ownership verification, data synchronization, and regulatory compliance.

Based on an in-depth analysis of mainstream RWA projects [1], we will outline the key paths for Pharos developers to build robust RWA applications from three dimensions: architectural patterns, core risk zones, and integration strategies.

Why is Pharos suitable for RWA?

Pharos is a Layer 1 application designed for internet-scale deployments. For RWA developers, there's no need to delve into the underlying consensus details; they only need to focus on solving the two core issues of asset settlement and complex computations.

1. Parallel execution and sub-second finality (Block-STM): Traditional EVMs process transactions serially, which can easily lead to congestion during large RWA payouts or rebalancing. Pharos introduces the Block-STM parallel execution engine to achieve sub-second finality.

• This means that off-chain funds can be received and on-chain settlement can be completed almost simultaneously, eliminating the exchange rate fluctuations and slippage risks brought about by "T+1".

1. Pharos natively supports a dual-VM architecture (EVM + WASM) with both EVM and WASM running environments.

• EVM Layer: Responsible for connectivity. Existing Solidity lending protocols and DEX code can be directly deployed to support RWA assets.

• WASM Layer: Responsible for computation. RWA involves complex interest taxation, tiered risk control, and compliance whitelist logic, which is extremely gas-intensive and inefficient on the EVM. This computationally intensive logic can be migrated to the WASM module to achieve high-performance, low-cost on-chain risk control.

https://docs.pharosnetwork.xyz

II. Two Operating Logics of RWA

Before designing the RWA protocol on Pharos, developers need to clarify two main asset transfer models and their funding loops:

1. On-chain to off-chain mode

This is currently the most common model, essentially involving on-chain fundraising and off-chain wealth management. Investors stake stablecoins (such as USDC) on-chain → the project team collects and converts them into fiat currency (USD) → invests in highly liquid off-chain assets (such as US Treasury bonds) → the interest earned flows back onto the blockchain and is distributed to token holders.

Case Study: Matrixdock's $STBT. Accredited investors mint $STBT (1:1 pegged to short-term US Treasury bonds), with the funds used by the project team to purchase Treasury bonds. On-chain holders enjoy an annualized yield of approximately 4.8%.

1. Asset on-chain model

This model focuses on the securitization and fragmentation of specific assets. The project team locks in specific off-chain assets (such as real estate) and values them → issues corresponding shares of ERC-20 tokens → investors subscribe with stablecoins → the project team is responsible for the maintenance and operation of off-chain assets → the generated cash flow (such as rent) is distributed as dividends on-chain periodically.

Case Study: RealT's Real Estate Tokenization. For example, a $65,900 property in Detroit could be split into 1,300 tokens, and investors who buy the tokens would be entitled to a share of the rental income from the property.

III. Risk Mapping and Pharos Integration Strategy

The fatal risks of RWA often lie not in the code itself, but in the connection between off-chain and on-chain mechanisms. Existing RWA projects have significant structural flaws in authentication, asset anchoring, and data transparency. Developers building applications on Pharos should focus on defending against the following gray rhino risks.

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

1. Penetrating identity compliance

Projects claiming compliance are often merely formalities. Statistics show that less than half of the projects implement effective KYC (Know Your Customer) procedures; some well-known projects (like RealT) have even had their video verification processes easily bypassed with a single photograph. While some projects emphasize AML (Anti-Malware and Cloud Computing) in their white papers, in practice, transactions can be completed simply by connecting a wallet, making it completely impossible to trace the source of funds.

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Pharos Development Recommendations:

• Do not only perform identity checks on the webpage frontend. A whitelist mechanism must be integrated at the smart contract layer to ensure that only addresses verified through DID (Decentralized Identity) or off-chain KYC can call the mint or transfer functions. Taking $STBT as an example, rewrite the ERC-20 transfer and transferFrom functions so that only certified whitelisted addresses can call them.

https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code

• For high-net-worth asset transactions, the 2FA mechanism should be introduced to prevent asset theft caused by private key leakage. Studies have shown that only a few projects have achieved this so far. 

1. Dependence on stablecoins and circuit breakers

Stablecoins are the lifeblood of RWA, with nearly 90% of projects relying on them for settlement. However, developers often overlook the decoupling risk inherent in stablecoins, such as the decoupling of USDC caused by the SVB incident or USDe [2]. If decoupling occurs, does the project have a dedicated risk reserve fund to handle the crisis?

https://x.com/ethena_labs/status/1976773136294224071

Pharos Development Recommendations:

• Oracles should not only be used for price feeding, but also as risk control triggers. When the price of a stablecoin used as the settlement currency (such as USDC/USDT) deviates from its peg by more than a threshold (such as 5%), the contract should automatically suspend minting and redemption to prevent the protocol from being attacked by arbitrage.

• When designing the liquidity pool, consider supporting multiple stablecoins or even a basket of currencies to mitigate the impact of systemic risk from a single asset. At the same time, avoid algorithmic stablecoins with complex mechanisms, as these are most prone to decoupling.

1. Data bridging and authenticity verification

The biggest black box surrounding RWA lies in whether on-chain assets truly correspond to off-chain physical assets. Many projects' so-called information disclosures are merely a few PDF files posted on a website; there have even been absurd cases of using looped video recordings to masquerade as real-time monitoring. OpenEden's net asset value report has also been delayed by up to a month.

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Pharos Development Recommendations:

• Utilize oracle networks such as Chainlink to directly connect to the APIs of off-chain custodian banks or auditing firms. Pharos developers should focus on achieving minute-level on-chain recording of Net Asset Value (NAV), rather than relying on monthly or quarterly reports from project teams.

• Project valuation discrepancies are a recurring risk. During development, multi-source oracle price feeds should be introduced to ensure that on-chain prices accurately reflect off-chain market conditions as much as possible.

1. Separation and Transparency of Legal Entities

Off-chain asset defaults are a risk that RWA cannot ignore. For example, Goldfinch once suffered a credit default of $5.9 million[4]. The key to isolating risks lies in SPVs, but only a few projects have publicly stated that they use SPV structures, and most of them have not disclosed the specific registered entity name. Taking the Goldfinch crisis as an example, it directly caused a 20% drop in the token, and investors suffered serious losses for no reason.

Pharos Development Recommendations:

• The legal name and place of registration of the SPV holding the assets must be disclosed in the project metadata or documentation.

• Ensure that each asset pool corresponds to an independent SPV. In Pharos' contract design, the funds in different asset pools should be logically completely isolated to avoid a single asset default causing the entire protocol to run out of liquidity.

1. Liquidity Depletion Following a False Prosperity

Liquidity is the easiest aspect of RWA projects to fake but also the easiest to collapse [2]. The market depth of many RWA projects in the early stages of their launch is highly dependent on market maker subsidies. Once the market maker agreement expires or the subsidies stop, the secondary market depth often drops sharply, and buy orders disappear instantly. In addition, there is a natural time mismatch between the low frequency of off-chain asset valuation (usually monthly or quarterly NAV) and the high frequency of on-chain transactions (second-level block generation). When a large amount of selling occurs on the chain, the AMM pool often cannot quickly replenish due to the lack of real-time fair value guidance, resulting in a serious deviation of the price from the net value and forming a liquidity black hole. For example, in the figure below, due to the run, the token price quickly dropped from $1 to $0.5 within a few hours [5].

https://www.blocktempo.com/not-so-tangible-usdr-stablecoin-collapses/

Pharos Development Recommendations:

• Don't gamble all your liquidity on the secondary market of DEX or CEX. Developers can build a buyback/redemption queue into their contracts. When the secondary market price is significantly lower than NAV (e.g., a discount of more than 3%), holders can bypass the secondary market and directly initiate redemption requests for the underlying assets of the SPV to the protocol, with the smart contract managing the redemption queue and fund distribution.

• Following the reserve system of traditional banks, a certain percentage (e.g., 5%-10%) of stablecoins is forcibly reserved as an on-chain liquidity buffer during the Mint process. This fund is not used to purchase off-chain assets, but is specifically used to automatically execute immediate buybacks via smart contracts to safeguard the price floor when secondary market liquidity dries up.

1. Risk of EVM native vulnerabilities being inherited

Pharos achieves full compatibility with the EVM, meaning that developers can enjoy the convenience of the Solidity ecosystem while also fully inheriting its classic attack vectors. Due to compliance requirements, RWA contracts typically contain numerous high-privilege functions (such as blacklist, forceTransfer, and pause), making permission management and proxy escalation more sensitive and critical weaknesses than DeFi protocols.

https://owasp.org/www-project-smart-contract-top-10/

Pharos Development Recommendations:

• Strictly adhere to standard libraries: Avoid reinventing the wheel. Access control must use OpenZeppelin's AccessControl or Ownable2Step. If RWA's administrator private key is stolen due to a custom logic vulnerability, it could lead to legal disputes regarding the ownership of off-chain physical assets.

• Agent upgrade risk control: RWA contracts are mostly upgradeable (UUPS/Transparent). When deploying updates, storage slot conflicts must be strictly checked to prevent dependent variable overwriting from causing asset mapping errors.

• Reentrancy attack defense: When handling distribution yield or redemption logic, even for whitelisted users, ReentrancyGuard must be added to all external calls to prevent malicious contracts from using callback functions to drain the fund pool.

IV. Summary

Looking back at the development of the RWA (Real-Time WA) sector, we've seen too many instances of false prosperity built on UI-based compliance and market-making to maintain liquidity. Within the Pharos ecosystem, we advocate for a more resilient development paradigm.

As developers, we need to be keenly aware that the security risks of RWA extend beyond the code implementation of smart contracts. Issues such as invalidation of off-chain asset ownership and liquidity mismatches also require attention . Pharos's sub-second finality gives us the confidence to handle complex financial transactions, but this demands that developers be more rigorous in their integration strategies, incorporating KYC/AML into the underlying logic, enforcing risk reserve mechanisms through code, and maximizing asset data transparency.

The future battle for RWA protocols will no longer be a numbers game of TVL, but a contest of asset authenticity and system robustness. Establishing a secure loop for this last mile is a mandatory course for every Pharos ecosystem builder.