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 reconstruct the complex challenges and solutions faced when bringing real-world assets (RWA) on-chain 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 entity rights and on-chain transactional properties. This dual nature dictates that its security perimeter cannot be confined solely to the smart contract layer 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: architectural patterns, core risk zones, and integration strategies.

1. 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 intricacies of the underlying consensus; the focus should be on solving the two core issues: asset settlement and complex computation.

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

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

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 logic for interest/tax calculations, tiered risk control, and compliance whitelisting, 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

2. Two Operational Logics for RWA

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

1. On-chain to Off-chain Model

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

Case Study: Matrixdock's $STBT. Accredited investors mint $STBT (pegged 1:1 to short-term U.S. Treasuries), the funds are used by the project to purchase government bonds, and on-chain holders enjoy an annualized yield of approximately 4.8%.

2. Asset On-chain Model

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

Case Study: RealT's real estate tokenization. For example, a property in Detroit valued at $65,900 is split into 1300 tokens, and investors buying these tokens gain rights to the rental income from that property.

3. Risk Landscape and Pharos Integration Strategies

The fatal risks of RWA often lie not in the code, but in the handover between off-chain and on-chain processes. Existing RWA projects exhibit 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.

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

1. Penetrative Identity Compliance

Projects claim compliance, but it's often superficial. Statistics show that less than half of projects implement effective KYC, and even well-known projects (like RealT) have had video verification steps that could be easily bypassed with a single photo. While some projects emphasize AML in their whitepapers, in practice, they often only require connecting a wallet to trade, making it impossible to trace fund sources.

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

Pharos Development Recommendation:

• Do not perform identity checks only on the web frontend. It is essential to integrate a whitelist mechanism at the smart contract layer, ensuring that only addresses verified through DID (Decentralized Identity) or off-chain KYC can call mint or transfer functions. Taking $STBT as an example, rewrite the ERC-20 transfer and transferFrom functions so that only authenticated whitelisted addresses 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 indicates that currently, only a minority of projects have implemented this.

2. Stablecoin Dependency and Circuit Breakers

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

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

Pharos Development Recommendation:

• Oracles should not only be used for price feeds but also as risk control triggers. When monitoring that the price of the settlement stablecoin (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 on the protocol.
• When designing fund pools, consider supporting multiple stablecoins or even a basket of currencies to mitigate the impact of systemic risk from a single asset. Also, try to avoid complex algorithmic stablecoins in stablecoin selection, as these are most prone to de-pegging.

3. Data Bridging and Authenticity Verification

The biggest black box in RWA is whether the on-chain assets truly correspond to off-chain physical assets. Many projects' so-called information disclosure is merely posting a few PDF files on a webpage, and there have even been absurd cases of using looped video playback to impersonate real-time monitoring. OpenEden's Net Asset Value (NAV) reports have also been delayed by a month.

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

Pharos Development Recommendation:

• Utilize oracle networks like Chainlink to directly connect to APIs from off-chain custodian banks or audit 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 project teams.
• 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 and Transparency

Off-chain asset default is a risk that cannot be ignored in RWA, as seen when 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 the use of SPV structures, and most do not disclose the specific registered entity names. Taking the Goldfinch crisis as an example, it directly caused a 20% drop in the $GFI token, severely harming investors unexpectedly.

Pharos Development Recommendation:

• Mandate disclosure of the legal name and jurisdiction of 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 entire protocol's liquidity.

5. Liquidity Crunch After Artificial Prosperity

Liquidity is the aspect of RWA projects most easily faked but also most prone to collapse [2]. The initial market depth of many RWA projects is highly dependent on market maker subsidies. Once the market-making agreement expires or subsidies stop, secondary market depth often plummets, with buy orders disappearing instantly. Furthermore, there is a natural temporal mismatch between the low frequency of off-chain asset valuation (typically monthly or quarterly NAV) and the high frequency of on-chain trading (second-level block times). When large sell-offs occur on-chain, AMM pools often cannot quickly replenish due to the lack of real-time fair value guidance, causing prices to deviate severely from NAV and creating 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 Recommendation:

• Do not bet liquidity entirely on DEX or CEX secondary markets. Developers can build in a redemption queue function within the contract. When the secondary market price falls significantly below 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, with the smart contract managing the redemption queue and fund distribution.
• Emulate the reserve requirement 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. This fund is not used to purchase off-chain assets but is specifically reserved for executing instant buybacks via smart contracts when secondary market liquidity dries up, defending the price floor.

6. Inherited Risks from EVM Native Vulnerabilities

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

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

Pharos Development Recommendation:

• Strictly Adhere to Standard Libraries: Do not reinvent the wheel. For access control, always use OpenZeppelin's AccessControl or Ownable2Step. If an RWA admin's private key is stolen due to a custom logic vulnerability, it could lead to legal disputes over the ownership of the off-chain physical assets.
• Proxy Upgrade Risk Control: RWA contracts are often upgradeable (UUPS/Transparent). When deploying updates, strictly check for storage slot conflicts to prevent asset mapping table (Mapping) corruption due to variable overwriting.
• Reentrancy Attack Defense: When handling dividend distribution (Distribute Yield) or redemption logic, even for whitelisted users, always add ReentrancyGuard to all external calls to prevent malicious contracts from draining the fund pool using callback functions.

4. Summary

Looking back at the development of the RWA sector, we have seen too much artificial prosperity built on UI-wrapped compliance and market maker-sustained liquidity. Within the Pharos ecosystem, we advocate for a more resilient development paradigm.

As developers, it is crucial to recognize clearly: The security risks of RWA do not only exist at the smart contract code implementation level; security issues such as the failure of off-chain asset verification and liquidity mismatch should also be taken seriously. Pharos's sub-second finality gives us confidence in handling complex financial operations, but this demands even greater rigor in integration strategies from developers: embedding KYC/AML into the underlying logic, enforcing risk reserve fund systems through code, and pushing asset data transparency to its limits.

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

References:

1. Safety
   Developer
   RWA