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

Jan 21, 2026 14:55:59

Share to

# Introduction

The Pharos ecosystem is dedicated to becoming the infrastructure that connects 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 duality determines that their security boundaries cannot be limited to the smart contract level but must extend to every gap in asset confirmation, 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 areas, and integration strategies.

## 1. Why is Pharos Suitable for RWA?

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

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

This means that off-chain fund arrivals and on-chain settlements can be nearly synchronized, eliminating the exchange rate fluctuations and slippage risks associated with "T+1".

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

EVM Layer: Responsible for connectivity. Existing Solidity lending protocols and DEX code can be directly deployed to accommodate RWA assets.
WASM Layer: Responsible for computation. RWA involves complex interest taxation, tiered risk control, and compliance whitelist logic, which incur high gas fees and low efficiency on EVM. Such computation-intensive logic can be migrated to WASM modules for high performance and low-cost on-chain risk control.

[https://docs.pharosnetwork.xyz]

## 2. Two Operational Logics of RWA

Before designing RWA protocols on Pharos, developers need to clarify two mainstream asset circulation models and their funding loops:

On-chain to Off-chain Model

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

Case Study: Matrixdock's $STBT. Qualified investors mint $STBT (1:1 pegged to short-term U.S. Treasury bonds), with funds used by the project to purchase Treasury bonds, allowing on-chain holders to enjoy approximately 4.8% annualized returns.

Asset On-chain Model

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

Case Study: RealT's property tokenization. For example, a property in Detroit valued at $65,900 is split into 1,300 tokens, allowing investors who buy tokens to enjoy rental income rights from that property.

## 3. Risk Map and Pharos Integration Strategy

The fatal risks of RWA often lie not in the code but in the connections between on-chain and off-chain. Existing RWA projects exhibit significant structural flaws in identity verification, 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]

Penetrative Identity Compliance

Projects claim compliance but often only pay lip service. Statistics show that less than half of projects have implemented effective KYC, and even well-known projects (like RealT) have had video verification processes that could be easily bypassed with a single photo. Some projects emphasize AML in their whitepapers but allow trading simply by connecting a wallet, making it 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 web front end. A whitelist mechanism must be integrated at the smart contract level to ensure that only addresses verified through DID (Decentralized Identity) or off-chain KYC can call mint or transfer functions. For example, for $STBT, 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, introduce a 2FA mechanism to prevent asset theft due to private key leakage; studies show that currently, only a few projects have achieved this.

Dependence on Stablecoins and Circuit Breakers

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

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

Pharos Development Recommendations:

Oracles should not only be used for price feeds but also as risk control triggers. When the price of the stablecoin used for settlement (like USDC/USDT) deviates from its peg by more than a threshold (like 5%), the contract should automatically pause minting and redemption to prevent the protocol from being exploited.
When designing liquidity pools, consider supporting multiple stablecoins or even a basket of currencies to mitigate the impact of systemic risks from a single asset. Additionally, avoid algorithmic stablecoins with complex mechanisms, as they are most prone to decoupling.

Data Bridging and Authenticity Verification

The biggest black box in RWA is whether on-chain assets truly correspond to off-chain physical entities. Many projects' so-called information disclosures merely consist of a few PDF files on their websites, and there have even been absurd cases of using looping videos to impersonate real-time monitoring. OpenEden's asset net value reports have also been known to be delayed by a month.

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

Pharos Development Recommendations:

Utilize oracle networks like Chainlink to directly connect to the APIs of off-chain custodial banks or auditing firms. Pharos developers should strive to achieve minute-level on-chain asset net value (NAV) rather than relying on monthly or quarterly reports from the project.
Valuation deviation risks can occur. During development, introduce multi-source oracles for price feeds to ensure that on-chain prices accurately reflect the off-chain market.

Isolation and Transparency of Legal Entities

Off-chain asset defaults are a risk that cannot be ignored in RWA, such as Goldfinch experiencing a $5.9 million credit default[4]. The key to isolating risks lies in SPVs, but only a few projects publicly declare the use of SPV structures, and most do not disclose the specific registered entity names. For example, the Goldfinch crisis directly caused a 20% drop in the $GFI token, leaving investors baffled and severely impacted.

Pharos Development Recommendations:

In the project metadata or documentation, mandate the disclosure of the SPV legal name and registration location holding the assets.
Ensure that each asset pool corresponds to an independent SPV. In Pharos's contract design, funds from different asset pools should be logically completely isolated to prevent a single asset default from causing liquidity depletion across the entire protocol.

Liquidity Depletion After False Prosperity

Liquidity is the aspect of RWA projects that is easiest to fabricate but also the most prone to collapse[2]. Many RWA projects initially rely heavily on market maker subsidies for depth. Once the market-making agreements expire or subsidies stop, secondary market depth often experiences a cliff-like drop, with buy orders vanishing instantly. Additionally, the low frequency of off-chain asset valuations (usually monthly or quarterly NAV) and the high frequency of on-chain transactions (seconds per block) create a natural time mismatch. When large sell-offs occur on-chain, AMM pools often cannot quickly replenish due to a lack of real-time fair value guidance, leading to severe price deviations from NAV and creating liquidity black holes. For example, with $USDR, due to a bank run, the token price rapidly dropped from $1 to $0.5 within a few hours[5].

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

Pharos Development Recommendations:

Do not rely entirely on DEX or CEX secondary markets for liquidity. Developers can embed buyback/redemption queue functions in contracts. When secondary market prices fall significantly below NAV (e.g., a discount of over 3%), allow holders to bypass the secondary market and directly initiate redemption requests for the underlying SPV assets, with smart contracts managing the redemption queue and fund distribution.
Mimic traditional banks' reserve systems by mandating a certain percentage (e.g., 5%-10%) of stablecoins to be retained as an on-chain liquidity buffer during the minting process. This fund should not be used to purchase off-chain assets but should be specifically allocated for automatic buybacks via smart contracts when secondary market liquidity is depleted, maintaining price floors.

Inheritance Risks of EVM Native Vulnerabilities

Pharos achieves full compatibility with EVM, meaning developers enjoy the conveniences of the Solidity ecosystem while fully inheriting its classic attack vectors. RWA contracts typically contain many high-privilege functions (like blacklist, forceTransfer, pause) due to compliance requirements, making permission management and proxy upgrades more sensitive and a fatal weakness compared to DeFi protocols.

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

Pharos Development Recommendations:

Strictly Adhere to Standard Libraries: Do not reinvent the wheel. Permission control must use OpenZeppelin's AccessControl or Ownable2Step. If the RWA administrator's private key is stolen due to custom logic vulnerabilities, it means ownership of off-chain physical assets will lead to legal disputes.
Proxy Upgrade Risk Control: RWA contracts are often upgradeable (UUPS/Transparent). When deploying updates, strictly check for storage slot conflicts to prevent variable overwrites that could disrupt the asset mapping table.
Reentrancy Attack Defense: When handling distribution of yields or redemption logic, even for whitelisted users, always add ReentrancyGuard to all external calls to prevent malicious contracts from draining liquidity pools through callback functions.

## Conclusion

Reflecting on the development of the RWA track, we have seen too many false prosperities relying on UI compliance and market-making to maintain liquidity. In the Pharos ecosystem, we advocate for a more resilient development paradigm.

As developers, it is crucial to recognize that the security risks of RWA exist not only at the code implementation level of smart contracts but also in issues such as the failure of off-chain asset confirmation and liquidity mismatches. Pharos's sub-second finality gives us the confidence to handle complex financial operations, but this requires developers to be more rigorous in their integration strategies, embedding KYC/AML into the underlying logic, enforcing risk reserve systems through code, and achieving maximum transparency in asset data.

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