Pharos Ecosystem Security Guide: Full-Chain 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) onto the blockchain from the perspectives of business logic and risk control architecture.

Introduction

The Pharos ecosystem is dedicated to becoming the infrastructure connecting traditional financial assets with the Web3 world. Unlike native crypto assets, real-world assets (RWA) possess both off-chain physical rights and on-chain trading attributes. This dual nature determines that their security boundaries cannot be confined solely to smart contracts but must extend to asset rights confirmation, data synchronization, and compliance regulation at every gap.

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

1. Why is Pharos suitable for RWA?

Pharos is a Layer 1 designed for internet-scale. For RWA developers, there is no need to delve into the underlying consensus details—just focus on solving core issues like asset settlement and complex calculations.

Parallel execution and sub-second confirmation (Block-STM) Traditional EVM processes transactions serially, which can easily cause congestion during large RWA distributions or rebalancing. Pharos introduces Block-STM parallel execution engine to achieve sub-second finality.

This means that off-chain fund arrivals and on-chain settlements can almost be completed simultaneously, eliminating the exchange rate fluctuations and slippage risks caused by “T+1”.

Dual-VM architecture (EVM + WASM) Pharos natively supports both EVM and WASM runtime environments.

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

WASM Layer: Responsible for computation. RWA involves complex interest taxation, tiered risk control, and compliance whitelist logic, which are costly and inefficient to run on EVM. These computationally intensive logics can be migrated to WASM modules to achieve high performance and low-cost on-chain risk management.

2. Two operational logics of RWA

Before designing RWA protocols on Pharos, developers need to clarify two main asset circulation models and their capital flows:

On-chain to off-chain transfer model

This is currently the most common pattern—essentially on-chain fundraising and off-chain wealth management. Investors stake stablecoins (e.g., USDC) on-chain → project team pools funds and exchanges for fiat currency (USD) → invests in high-liquidity off-chain assets (e.g., U.S. Treasuries) → interest income flows back on-chain and is distributed to token holders.

Example: Matrixdock’s $STBT. Qualified investors mint $STBT (pegged 1:1 to short-term U.S. debt), with funds used by the project to purchase government bonds. On-chain holders enjoy approximately 4.8% annual yield.

Asset on-chain model

This pattern focuses on securitization and fragmentation of specific assets. The project locks in specific off-chain assets (e.g., real estate) and appraises their value → issues corresponding ERC-20 tokens → investors subscribe with stablecoins → the project maintains and operates the off-chain assets → cash flows (e.g., rent) are periodically distributed on-chain.

Example: RealT’s real estate tokenization. For instance, a property in Detroit valued at $65,900 is split into 1300 tokens, and investors buy tokens to enjoy rental income rights.

3. Risk landscape and Pharos integration strategies

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

Penetrative identity compliance

Some projects claim compliance but are merely superficial. Statistics show that less than half of projects implement effective KYC; even well-known projects (like RealT) have video verification steps that can be easily bypassed with a single photo. Some projects emphasize AML in whitepapers but in practice only require wallet connection to trade, making it impossible to trace fund sources.

Pharos development suggestions:

Do not rely solely on front-end identity checks. Integrate whitelist mechanisms at the smart contract level to ensure only addresses verified via DID (Decentralized Identity) or off-chain KYC can call mint or transfer functions. For example, rewrite ERC-20’s transfer and transferFrom functions so that only whitelisted, verified addresses can invoke them.

For high-net-worth asset transactions, introduce 2FA mechanisms to prevent asset theft due to private key leaks. Studies show only a few projects currently implement this.

Dependence on stablecoins and circuit breakers

Stablecoins are the lifeblood of RWA—about 90% of projects rely on stablecoins for settlement. However, developers often overlook the de-pegging risks of stablecoins, such as USDC de-pegging after the SVB incident or USDe risks$STBT . If de-pegging occurs, does the project have dedicated risk reserves to handle the crisis?

Pharos development suggestions:

Oracles should do more than just price feeds—they should serve as risk triggers. When the stablecoin used for settlement (e.g., USDC/USDT) deviates from its peg beyond a threshold (e.g., 5%), the contract should automatically pause minting and redemption to prevent arbitrage attacks.

Design liquidity pools supporting multiple stablecoins or a basket of currencies to reduce systemic risk from a single asset. Also, avoid overly complex algorithmic stablecoins, as they are most prone to de-pegging.

Data bridging and authenticity verification

The biggest black box of RWA is whether on-chain assets truly correspond to off-chain physical assets. Many projects’ disclosures are just a few PDFs on a website, and some have even used looping videos to pretend to be real-time monitoring—ridiculous cases. OpenEden’s net asset value (NAV) reports have also been delayed by a month.

Pharos development suggestions:

Use oracle networks like Chainlink to directly connect to APIs of off-chain custodian banks or auditing agencies. Developers should aim to achieve minute-level on-chain NAV updates rather than relying on monthly or quarterly reports from project teams.

Valuation deviations are common. Incorporate multi-source oracle feeds to ensure on-chain prices reflect off-chain market conditions as accurately as possible.

Legal entity isolation and transparency

Off-chain asset defaults are an unavoidable risk in RWA, such as Goldfinch’s $5.9 million credit default[2]. The key to risk isolation is the SPV (Special Purpose Vehicle), but only a few projects publicly disclose using an SPV structure, and most do not reveal specific registered entity names. For example, the Goldfinch crisis caused a 20% drop in [4] tokens, severely damaging investors’ interests.

Pharos development suggestions:

Require disclosure of the legal name and registration location of the SPV holding the assets in project metadata or documentation.

Ensure each asset pool corresponds to an independent SPV. In smart contract design, funds from different pools should be logically isolated to prevent a single asset default from causing the entire protocol’s liquidity to dry up.

Liquidity exhaustion after false prosperity

Liquidity is the most easily faked and yet most fragile link in RWA projects$GFI . Many RWA projects initially rely heavily on market maker subsidies for depth. Once the market maker agreement expires or subsidies stop, secondary market depth often collapses sharply, with buy orders vanishing instantly. Additionally, the low-frequency valuation of off-chain assets (monthly or quarterly NAV) and the high-frequency on-chain trading (seconds per block) create a natural time mismatch. When large sell-offs occur on-chain, AMM pools often cannot quickly rebalance due to lack of real-time fair value signals, causing prices to deviate significantly from NAV and forming liquidity black holes. The example below [2] shows a run causing the token price to drop from $1 to $0.5 within hours$USDR .

Pharos development suggestions:

Do not rely solely on DEX or CEX secondary markets for liquidity. Embed buyback/redemption queues in the contract. When the secondary market price drops significantly below NAV (e.g., more than 3% discount), allow holders to bypass the secondary market and directly initiate redemption requests against the underlying SPV assets, with the smart contract managing queues and fund distribution.

Implement a reserve system similar to traditional banks: during minting, forcibly retain a certain percentage (e.g., 5%-10%) of stablecoins as an on-chain liquidity buffer. These funds are not used to purchase off-chain assets but are reserved for automatic on-chain buybacks during liquidity crises, maintaining price floors.

Inherited risks of EVM-native vulnerabilities

Pharos achieves full compatibility with EVM, meaning developers enjoy the convenience of Solidity ecosystems but also inherit its classic attack vectors. RWA contracts, due to compliance requirements, often contain many high-permission functions (e.g., blacklist, forceTransfer, pause), making permission management and proxy upgrades more sensitive and critical vulnerabilities than typical DeFi protocols.

Pharos development suggestions:

Strictly adhere to standard libraries: avoid reinventing the wheel. Use OpenZeppelin’s AccessControl or Ownable2Step for permission control. If the admin private key is compromised due to custom logic bugs, it could lead to legal disputes over physical asset ownership.

Proxy upgrade risk control: RWA contracts are often upgradeable (UUPS/Transparent). When deploying updates, carefully check storage slot conflicts to prevent variable overwrites that could corrupt asset mappings.

Reentrancy attack prevention: When handling dividends (Distribute Yield) or redemptions, even for whitelisted users, add ReentrancyGuard to all external calls to prevent malicious contracts from exploiting callbacks to drain funds.

4. Summary

Looking back at the development of the RWA track, we have seen too many false prosperity stories relying on UI packaging of compliance and market-making to sustain liquidity. In the Pharos ecosystem, we advocate a more resilient development paradigm.

Developers must clearly recognize that: the security risks of RWA are not only in smart contract code but also in the failure of off-chain asset rights confirmation and liquidity mismatches. Pharos’s sub-second finality gives us confidence to handle complex financial operations, but this requires developers to be more rigorous in integration strategies—embedding KYC/AML into core logic, enforcing risk reserves through code, and maximizing transparency of asset data.

The future competition among RWA protocols will no longer be a TVL number game but a contest of asset authenticity and system robustness. Closing this final security loop is a mandatory course for every builder in the Pharos ecosystem.