Pharos Ecosystem Security Guide: Full-Link Risk Control for RWA Asset Integration

This article aims to provide developers within the Pharos ecosystem with a more practical and in-depth reference for RWA integration. We attempt to restore the complex challenges and countermeasures faced when bringing Real World Assets (RWA) on-chain from the perspectives of business logic and risk control architecture.

Introduction

The Pharos ecosystem is committed to becoming the infrastructure connecting traditional financial assets with the Web3 world. Unlike native crypto assets, Real World Assets (RWA) possess both off-chain entity rights and on-chain trading attributes. This dual nature dictates that its security boundary cannot stop only at the smart contract level but must extend into every crevice of asset verification, data synchronization, and compliance regulation.

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

I. Why is Pharos Suitable for RWA?

Pharos is a Layer 1 blockchain designed for internet-scale. For RWA developers, there's no need to delve into the underlying consensus details; focus should be on solving the two core aspects: asset settlement and complex computation.

1. Parallel Execution & Sub-Second Finality (Block-STM) Traditional EVM processes transactions serially, which can easily cause congestion during large RWA distributions or rebalancing. Pharos introduces the Block-STM parallel execution engine, achieving sub-second finality.

• This means off-chain fund arrival and on-chain settlement can be almost synchronized, eliminating the exchange rate fluctuation and slippage risks associated with "T+1".

2. Dual-VM Architecture (EVM + WASM) Pharos natively supports dual runtime environments: EVM and WASM.

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

• WASM Layer: Responsible for computation. RWA involves complex interest tax calculations, tiered risk control, and compliance whitelist logic, which is extremely gas-intensive and inefficient to run on EVM. Such computation-intensive logic can be migrated to WASM modules, enabling high-performance, low-cost on-chain risk control.

https://docs.pharosnetwork.xyz

II. Two Operational Logics of RWA

Before designing RWA protocols on Pharos, developers need to understand the two mainstream asset circulation models and their capital circuits:

1. On-Chain to Off-Chain Model

This is currently the most common model, essentially involving on-chain fundraising and off-chain investment. Investors stake stablecoins (e.g., USDC) on-chain → the project party aggregates and converts them to fiat (USD) → invests in off-chain high-liquidity assets (e.g., US Treasury bonds) → the interest earned flows back on-chain and is distributed to token holders.

Case: Matrixdock's $STBT. Qualified investors mint $STBT (1:1 pegged to short-term Treasury bonds), the funds are used by the project party to purchase bonds, and on-chain holders enjoy an annualized yield of about 4.8%.

2. Asset On-Chaining Model

This model focuses on the securitization and fractionalization of specific assets. The project party locks a specific off-chain asset (e.g., real estate) and values it → issues corresponding ERC-20 tokens → investors subscribe with stablecoins → the project party is responsible for off-chain asset maintenance and operation → generated cash flow (e.g., rent) is periodically distributed on-chain as dividends.

Case: RealT's real estate tokenization. For example, a property in Detroit worth $65,900 is split into 1300 tokens; investors buying tokens gain the right to rental income from that property.

III. Risk Landscape & Pharos Integration Strategies

The fatal risks of RWA often lie not in the code but in the衔接环节 (connection points) between off-chain and on-chain. Existing RWA projects have significant structural deficiencies in identity verification, asset pegging, and data transparency. When building applications on Pharos, developers should focus on defending against the following gray rhino risks.

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

1. Penetrative Identity Compliance

Projects claim compliance but it's often superficial. Statistics show less than half of projects implement effective KYC; even well-known projects (like RealT) had video verification steps that could be easily fooled with a single photo. Some projects emphasize AML in whitepapers but in practice only require connecting a wallet to trade, making fund source tracing impossible.

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

Pharos Development Advice:

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

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

• For high-net-worth asset transactions, introduce a 2FA mechanism to prevent asset theft due to private key leakage; research shows only a minority of projects currently achieve this.

2. Stablecoin Dependency & Circuit Breakers

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

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

Pharos Development Advice:

• Oracles should not only be used for price feeds but also as risk control triggers. When monitoring shows the price of the settlement stablecoin (e.g., USDC/USDT) deviates from the peg beyond a threshold (e.g., 5%), the contract should automatically pause minting and redemption to prevent arbitrage attacks on the protocol.

• When designing capital pools, consider supporting multiple stablecoins or even a basket of currencies to mitigate the impact of single-asset systemic risk. Also, try to avoid complex algorithmic stablecoins in the choice of stablecoins, as these are most prone to depegging.

3. Data Bridging & Authenticity Verification

The biggest black box in RWA is whether the on-chain asset truly corresponds to the off-chain physical asset. Many projects' so-called information disclosure is just posting a few PDF files on a webpage; there have even been absurd cases of using looped videos冒充 (impersonating) real-time monitoring. OpenEden's Net Asset Value (NAV) reports have also been lagging by a month.

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

Pharos Development Advice:

• Utilize oracle networks like Chainlink to directly connect to APIs of off-chain custodian banks or auditing institutions. Pharos developers should strive to achieve minute-level on-chain updates of Net Asset Value (NAV), rather than relying on monthly or quarterly reports from the project party.

• Project valuation deviation risks occur from time to time. During development, introduce multi-source oracle price feeds to make the on-chain price reflect the off-chain market as accurately as possible.

4. Legal Entity Isolation & Transparency

Off-chain asset default is a non-negligible risk for RWA, for example, Goldfinch experienced a $5.9 million credit default [4]. The key to isolating risk lies in SPVs (Special Purpose Vehicles), but only a minority of projects publicly declare using an SPV structure, and most do not disclose the specific registered entity name. Taking the Goldfinch crisis as an example, it directly caused a 20% drop in the $GFI token, severely harming investors莫名其妙 (inexplicably).

Pharos Development Advice:

• Mandate disclosure of the legal name and jurisdiction of registration for the SPV holding the assets in the project metadata or documentation.

• Ensure each asset pool corresponds to an independent SPV. In Pharos contract design, funds from different asset pools should be logically completely isolated to prevent a single asset default from draining the protocol's overall liquidity.

5. Liquidity Drought After False Prosperity

Liquidity is the aspect of RWA projects most easily faked but also most prone to collapse [2]. The order book depth in the early stages of many RWA projects is highly dependent on market maker subsidies. Once the market making agreement expires or subsidies stop, the secondary market depth often plummets悬崖式 (cliff-like), with buy orders disappearing instantly. Furthermore, 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 trading (second-level block production). When large sell-offs occur on-chain, AMM pools often lack real-time fair value guidance and cannot quickly readjust, causing prices to deviate severely from NAV and forming a liquidity black hole. As shown in the example of $USDR below, due to a bank run, the token price rapidly dropped from $1 to $0.5 within hours [5].

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

Pharos Development Advice:

• Do not bet liquidity entirely on DEX or CEX secondary markets. Developers can build in回购/赎回队列 (buyback/redemption queue) functionality into the contract. When the secondary market price is significantly lower than NAV (e.g., a discount exceeding 3%), allow holders to bypass the secondary market and directly initiate redemption requests to the protocol against the SPV's underlying assets, managed by the smart contract for queuing and fund distribution.

• Imitate the reserve system of traditional banks by mandating the retention of a certain percentage (e.g., 5%-10%) of stablecoins as an on-chain liquidity buffer pool during the Mint process. These funds are not used to purchase off-chain assets but are specifically used for instant buybacks executed automatically by the smart contract when secondary market liquidity dries up, defending the price floor.

6. Inherited Risks of EVM Native Vulnerabilities

Pharos achieves full compatibility with EVM, meaning developers enjoy the convenience of the Solidity ecosystem while fully inheriting its classic attack vectors. Due to compliance needs, RWA contracts often contain numerous high-privilege functions (e.g., blacklist, forceTransfer, pause), making permission management and proxy upgrades a more sensitive critical weakness than in DeFi protocols.

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

Pharos Development Advice:

• Strict Adherence to Standard Libraries: Do not reinvent the wheel. For access control,务必 (must) use OpenZeppelin's AccessControl or Ownable2Step. If the admin private key of an RWA contract is stolen due to a vulnerability in custom logic, it means the ownership of the off-chain physical asset could become a legal dispute.

• Proxy Upgrade Risk Control: RWA contracts are often upgradeable (UUPS/Transparent). When deploying updates, storage slot conflicts must be strictly checked to prevent asset mapping tables from becoming混乱 (chaotic) due to variable overwriting.

• Reentrancy Attack Defense: When handling distribution logic (Distribute Yield) or redemption logic, even for whitelisted users, ReentrancyGuard must be added to all external calls (Call) to prevent malicious contracts from draining the fund pool using callback functions.

IV. Summary

Looking back at the development of the RWA track, we have seen too many cases of false prosperity relying on UI-packaged compliance and market making to maintain liquidity. Within the Pharos ecosystem, we advocate for a more resilient development paradigm.

As developers, it is necessary to清醒地认识到 (be清醒ly aware): RWA security risks exist not only at the smart contract code implementation level, but also in off-chain aspects like asset verification failure and liquidity mismatch. Pharos's sub-second finality gives us the confidence to handle complex financial business, but this requires developers to be more rigorous in integration strategies, embedding KYC/AML into the underlying logic, enforcing risk reserve fund systems through code, and maximizing asset data transparency.

The future competition among RWA protocols will no longer be a numbers game of TVL, but a contest of asset authenticity and system robustness. Securing this last mile of the safety loop is a required course for every builder in the Pharos ecosystem.