Understanding Pharos: A Comprehensive Overview

Key Insights

• Pharos is a modular Layer 1 blockchain designed to serve as global infrastructure for real-world assets (RWAs), founded by former Ant Group executives who led its blockchain infrastructure team.
• Unlike other chains that only parallelize execution, Pharos targets the entire block lifecycle, consensus, execution, storage, and data availability as a concurrent process, aiming to sustain 30,000 transactions per second (TPS) on mainnet.
• Pharos Store embeds the Merkle tree directly into the storage engine itself, collapsing the I/O path from eight to ten disk reads down to one to three. This targets an under-the-radar bottleneck that caps throughput on even the fastest parallel chains.
• Pharos unifies EVM and WASM under a single deterministic runtime (DTVM), allowing Solidity contracts to natively call Rust contracts with no bridges or cross-VM overhead.
• Special Processing Networks (SPNs) let developers spin up application-specific execution layers for demanding workloads, such as derivatives trading and ZK verification, inheriting mainnet security through native restaking rather than bootstrapping a new validator set from scratch.

Introduction

Pharos is a high-performance, modular Layer 1 blockchain designed to serve as global infrastructure for real-world assets (RWAs). The network offers sub-second block times and can handle a billion concurrent users. Its mission is to create an inclusive financial system that provides the speed of Web2 systems while maintaining the decentralized security of a public blockchain. By prioritizing quality over quantity in its asset ecosystem, Pharos aims to unlock liquidity for both financially underserved communities and established institutions.

What differentiates Pharos from other EVM networks is its high degree of parallelism (DP). Unlike other chains that only parallelize transaction execution, Pharos can run the entire lifecycle of a block (data availability, execution, settlement, and consensus) concurrently, using specialized hardware to boost performance. By removing these hidden bottlenecks at every level of the block lifecycle, Pharos can sustain 30,000 transactions per second (TPS) and 2 Gigabits per second, ensuring the network can handle the global scale of a billion users simultaneously.

After the success of its AtlanticOcean testnet (launched October 2025), Pharos is now preparing for its mainnet launch and Token Generation Event (TGE) in Q2 2026.

Background

Pharos was founded in November 2024 by Alex Zhang and Wish Wu, former executives of the blockchain infrastructure team at Ant Group, a fintech affiliate of Alibaba Group. Zhang served as the CEO of ZAN, a Web3 subsidiary of Ant Group Digital Technologies, and previously as the CTO of AntChain. Wu served as the Chief Security Officer at ZAN, bringing extensive experience in institutional-grade security and compliance.

Pharos was established as a spin-out to transform this infrastructure into a decentralized and public Layer 1 blockchain. The founding team combines deep technological expertise with backgrounds from Microsoft, PayPal, Stanford, and Ripple. In November 2024, Pharos raised an $8 million seed round co-led by Hack VC and Lightspeed Faction. Alongside this funding, Pharos entered a strategic partnership with ZAN focused on node infrastructure, security, and hardware acceleration to ensure the network is equipped for institutional-grade reliability.

Technology

Pharos targets the entire block lifecycle as a parallel process. Its architecture is built on the principle that if only execution is parallelized, the network will inevitably bottleneck at the storage I/O, consensus, or data availability stages.

To eliminate these bottlenecks, Pharos employs a modular stack that decouples execution, consensus, and settlement, underpinned by a custom-built storage engine and a dual-virtual machine environment.

Consensus Layer

Traditional Byzantine-Fault-Tolerant (BFT) consensus mechanisms rely on a single leader to propose a block, creating a performance ceiling and a single point of failure. Pharos eliminates this constraint through a fully asynchronous BFT protocol that operates without fixed timing assumptions, allowing validators to advance dynamically based on actual network conditions rather than arbitrary timeouts. Most round-based BFT protocols require the network to wait for prior rounds to finalize before proceeding, tying throughput to worst-case latency. Pharos decouples the block proposing phase from the committing phase, so validators process transactions based on real-time network capacity. This prevents stalls during volatile conditions and maximizes throughput without sacrificing safety guarantees. The protocol maintains liveness even under full asynchrony, where message delivery times are unpredictable.

To prevent duplicate transactions from flooding the network, a deterministic mapping algorithm assigns each transaction to a designated validator. The diagram above illustrates this clearly. Transactions from the mempool are partitioned so that validator1 receives tx1 and tx2, validator2 receives tx3 and tx4, and validator3 receives tx5, while validator4, having no assigned transactions in this round, sits idle rather than rebroadcasting redundant data. Each active validator then packages its assigned transactions into an independent proposal. The result is that network resources scale linearly as validators join (doubling the validator set roughly doubles the aggregate proposal bandwidth), rather than creating more idle nodes.

Once validators concurrently submit their proposals, all proposals feed into a dense all-to-all voting process. If at least two-thirds of validators agree on the proposals, the network merges reliable broadcast and consensus voting into a single streamlined process that commits the block in just three communication rounds. The output is a single finalized block containing the deduplicated, ordered transaction list.

Execution Layer

At the heart of the Pharos execution layer is the DeTerministic Virtual Machine (DTVM) stack, which replaces the standard sequential processing model with a parallel, dual-VM architecture.

The DTVM Stack

DTVM natively supports both EVM and WASM execution under a single runtime, eliminating the need for separate virtual machines and enabling frictionless cross-contract interoperability between Solidity contracts and those written in languages like Rust, Go, and C++. To enforce strict determinism across diverse hardware, DTVM compiles all bytecode into a Deterministic Middle Intermediate Representation (dMIR), a unified, platform-agnostic translation layer that strips out non-deterministic behaviors such as floating-point ambiguities and unspecified trap handling. dMIR enforces standardized halt conditions, strict numerical computation rules, and a fixed-size virtual call stack (8MB with a 1,024-call depth limit) independent of the host system, guaranteeing exact state replication across every node regardless of whether it runs on x86 or ARM.

Because dMIR acts as a common backend for multiple bytecode frontends, a single optimized Just-In-Time (JIT) compiler can service EVM, WASM, and potentially RISC-V contracts, avoiding the fragmentation and redundant VM overhead that plagues multi-VM architectures. Only modules that successfully compile to dMIR are cleared for execution, making the IR itself a determinism gatekeeper.

To minimize the latency traditionally associated with JIT compilation, DTVM incorporates the Zeta Engine. Most blockchain VMs face an uncomfortable tradeoff between compiling everything upfront and delaying deployment, or compiling on first invocation and delaying execution. Zeta sidesteps this by compiling at the function level rather than the contract level. When a contract is deployed, the engine validates it, generates dMIR, and begins compiling individual functions asynchronously in the background. If a function is called before its compilation finishes, a lightweight stub triggers on-demand compilation and then patches itself so that every subsequent call hits optimized native code directly. The result is a first-invocation latency of just 0.95 milliseconds, with native code execution from the second call onward.

Pharos Pipelining

Pharos Pipelining ties these components together by deconstructing the sequential block lifecycle into concurrent stages. In a typical blockchain, a block is proposed, then executed, and finally committed, with each stage waiting for the previous to finish. Pharos runs execution, merklization, and state finalization simultaneously in overlapping pipelines using a 64-core framework that dynamically allocates CPU and disk I/O resources, so hardware is never sitting idle.

This architecture also provides flexible, multi-tier finality. Pharos separates ordering finality (permanent transaction sequencing), transaction finality (deterministic execution results), and block finality (access to the fully finalized block). Applications can receive early confirmation of transaction ordering and execution results before the block fully finalizes, a meaningful UX improvement for latency-sensitive use cases like trading and gaming, while infrastructure components like oracles and indexers wait for full block finality.

This pipelining enables Pharos to achieve a throughput of 500,000 TPS in optimized environments, resulting in 30-50% lower latency than traditional sequential pipelining models.

Ph-WASM

The EVM is historically inefficient for compute-intensive tasks; its 256-bit word size, stack-based architecture, and lack of native support for modern hardware features impose a hard performance ceiling. Ph-WASM is Pharos' specialized WebAssembly runtime, designed to run alongside the EVM and handle workloads that demand higher throughput, such as AI model orchestration, onchain trading of perpetual futures onchain, and ZK proof verification. High-level compiler optimizations, including SIMD vectorization and opcode fusion, keep both CPU-bound and I/O-bound operations fast and resource-efficient.

The practical impact is that developers can write performance-critical logic in languages like Rust or C++ and deploy it to Ph-WASM while keeping their existing Solidity contracts on the EVM side. Because both VMs compile down to the same dMIR layer, a Solidity contract can call a Rust contract natively, no bridges, no nested VM execution, no inter-process communication overhead. This means liquidity and composability stay unified across both runtimes. A DeFi protocol, for example, could run its user-facing vault logic in Solidity for ecosystem compatibility while offloading its pricing engine to a Rust contract on Ph-WASM for the raw throughput that dynamic, real-time applications require.

Storage Layer

State bloat and slow disk I/O are the silent killers of onchain scalability. Even the fastest execution engine will stall if it has to wait for a traditional Merkle Patricia Trie (MPT) to read from disk. Ethereum's MPT, for instance, requires eight to ten separate disk reads just to access a single account's state, and its hash-based addressing causes constant database compactions that consume massive amounts of disk bandwidth. As a network scales to hundreds of millions of accounts, these costs compound until storage becomes the binding constraint on throughput, not execution or consensus.

Pharos Store is a blockchain-native storage engine built on Log-Structured Efficient Trusted Universal Storage (LETUS) principles, designed to eliminate these bottlenecks at the architectural level. Its core innovation is Authenticated Data Structure (ADS) pushdown. Rather than layering a Merkle tree on top of a separate key-value database (the standard two-layer design), Pharos Store embeds the Merkle tree directly into its storage engine. This collapses the I/O path from eight to ten disk reads down to one to three, a structural improvement that compounds with every transaction the network processes.

The engine organizes data around three purpose-built structures:

• The Delta-Encoded Multi-Version Merkle Tree (DMM-Tree) is a high-fanout Merkle tree with built-in delta-encoding, meaning only modified state changes are persisted rather than full node rewrites.
• The Log-Structured Versioned Page Store (LSVPS) provides a page-level index abstraction between memory and disk for the DMM-Tree, using monotonically increasing version numbers instead of hash-based addressing. This version-based indexing eliminates the heavy compaction cycles that plague traditional LSM-tree backends, reducing disk bandwidth consumption by 96.5%.
• The Versioned Data Logging Stream (VDLS) stores user metadata in an append-only log, ensuring data integrity and enabling fast recovery after node crashes.

According to the team, Pharos Store reduces storage overhead by 80% and delivers 15.8 times the I/O throughput of Ethereum's MPT and LevelDB stack. For parallel execution specifically, the engine supports concurrent reads, multi-threaded Merkle hash computation, and non-blocking writes, ensuring that storage keeps pace with the execution layer rather than throttling it. The system also supports tiered storage, automatically migrating older block data from fast SSDs to cheaper archival storage, and boundary-scan-based pruning that has reduced storage footprints by over 42% in production tests.

Networking Layer

The networking layer underpins all communication in the Pharos system using an optimized P2P gossip protocol for low-latency message propagation. The system implements adaptive bandwidth allocation based on real-time network load, ensuring efficient transaction and data dissemination even under stress.

Special Purpose Networks (SPNs)

Pharos introduces Special Processing Networks (SPNs) to allow for modular, application-specific scaling. An SPN is essentially a custom execution layer that inherits Pharos' security while operating semi-independently with its own consensus parameters and logic. Developers can configure an SPN for compute-intensive workloads that would be impractical or uneconomical to run on a general-purpose chain, such as Fully Homomorphic Encryption (FHE), multiparty computation (MPC), AI model inference, and high-frequency trading.

SPNs bootstrap their security through native restaking. Validators on the Pharos mainnet can stake native tokens and receive a liquid staking certificate, which they then restake into one or more SPNs. This creates a shared security blanket that makes launching a specialized sub-network both secure and capital-efficient, rather than forcing each new environment to attract its own independent validator set from scratch.

To move assets and data between SPNs and the main chain, users leverage the SPN Interoperability Protocol, which is built around three core components: a Mailbox, a Registry, and a Bridge. Unlike generic Layer-2s, this protocol is deeply integrated with Pharos' primary network, enabling low-latency message relaying and atomic asset transfers that prevent the liquidity fragmentation common in multichain architectures.

Cross-SPN communication relies on several steps:

• A user initiates a cross-SPN transaction within SPN1, targeting execution in SPN2's message queue.
• A Relayer transmits the transaction, along with its cryptographic proof and block header, to the Primary Network.
• The Primary Network verifies the transaction's authenticity and records it in the Mailbox, serving as the canonical source of truth for cross-SPN messages.
• SPN2 retrieves the message from the Mailbox and records it within its own local Mailbox, completing the execution handoff.

This flow is governed by two key smart contract layers. The SPN Adapter handles message verification and cross-SPN routing at the protocol level, while the SPN Manager oversees lifecycle management, registry state, and governance, ensuring each SPN's configuration remains consistent with the broader Pharos network. Together, these components enable atomic execution and verifiable data sharing across SPNs without relying on trusted intermediaries.

The design also incorporates built-in escape hatches, ensuring censorship resistance by guaranteeing that users can always withdraw assets to the main chain regardless of SPN operator behavior, a critical safeguard for high-stakes use cases like DeFi derivatives and institutional asset management.

Ecosystem

In preparation for its mainnet launch and TGE in Q2 2026, Pharos Foundation, the project’s nonprofit designed to oversee the development and ecosystem of Pharos Network solutions, has coordinated a comprehensive ecosystem, inclusive of real-world assets (RWAs), BTCfi, DEXs, Perp DEXs, a prediction market, liquid staking (LST), yield farming and automation, AI and agentic banking, lending and borrowing protocols, and infrastructure, including indexing, RPC, oracles, multisig, block explorers, security, crosschain interoperability, and wallets.

The ecosystem is focused on “RealFi,” a term used to describe institutional-grade finance built onchain via RWAs rather than DeFi yield from crypto native assets. RealFi is intended to be open by default, with RWAs accessible to all via issuers like Centrifuge, which will be issuing its tokenized U.S. Treasuries product JTRSY and AAA-rated structured credit product JAAA on Pharos.

To realize open access to RWAs in an environment where fragmentation remains the primary barrier to institutional RWA adoption, Pharos Foundation has announced the RealFi Alliance. On Pharos, and under this alliance:

• Chainlink serves as the canonical crosschain infrastructure for secure messaging and data integrity. Pharos has also adopted Chainlink Data Streams for price data for its RWA markets. LayerZero provides interoperability, and TopNod provides a secure self-custodial wallet.
• Centrifuge issues freely transferable, fully composable RWAs via its deRWA token standard, which wraps existing tokenized securities into freely transferable tokens fully composable with DeFi protocols.
• Anchorage Digital, the first federally regulated crypto bank in the United States, provides institutional-grade custody, token minting, and asset distribution. This includes for venture investors receiving tokens from Pharos’ upcoming token generation event (TGE).
• R25 will introduce RWA-backed protocols focused on structured credit and transparent yield design.
• Faroo will provide a liquid staking protocol for RWAs on Pharos.

The RealFi Alliance will expand in structured batches, with future members selected based on asset quality, technical readiness, and ecosystem alignment. On top of this, Pharos has announced a $10 million RealFi builder incubator program designed to support early-stage teams building DeFi applications and infrastructure on Pharos. Partners for the incubator include Hack VC, Draper Dragon, Lightspeed Faction, and Centrifuge.

Closing Summary

Pharos is built on the thesis that parallelizing transaction execution alone is insufficient. By designing the entire block lifecycle, consensus, execution, storage, and data availability as a concurrent process, the network attempts to address the structural bottlenecks that have historically capped Layer 1 throughput. Its DTVM stack unifies EVM and WASM under a single deterministic runtime, while Pharos Store aims to collapse storage I/O from eight to ten disk reads down to one to three, targeting what has long been an overlooked constraint on onchain scalability.

Special Processing Networks could offer a modular path toward scaling without fragmenting liquidity across isolated execution environments. With both TGE and mainnet launch expected in Q2 2026, the project's trajectory will ultimately be determined by its ability to translate architectural design into live network performance and adoption of RealFi on Pharos.