Pharos Network's technical approach emphasizes high performance and parallel processing capabilities, which theoretically helps support application scenarios such as high-frequency interactions, payment settlements, and high concurrency demands. However, technical performance advantages alone are insufficient to guarantee the network's long-term competitiveness. How to translate the underlying infrastructure capabilities into real and sustainable application requirements, and on this basis, foster a developer and application ecosystem, is a crucial challenge that Pharos Network will face in its future development.
Author: Web3Caff Editorial Department
As blockchain infrastructure competition shifts from "general-purpose public chain competition" to "performance optimization for specific application scenarios," the underlying architecture surrounding high-performance applications is becoming a key focus of the new round of infrastructure competition. On the one hand, the demand for real-world assets, Web2 commercial applications, and on-chain mapping continues to grow, and some application scenarios closely linked to the real economy are gradually becoming important bridges connecting on-chain systems and the real world. On the other hand, these application scenarios also place more stringent technical requirements on the throughput, deterministic execution, and low latency characteristics of blockchain systems.
Against this backdrop, Pharos Networks is attempting to build a Layer 1 network with high parallel processing capabilities and low latency through modular architecture design and comprehensive optimization of the underlying system, in order to meet the dual performance and scalability requirements of future commercial and financial applications.
However, is Pharos Network's vision truly feasible? What are the differentiating features of its architecture? How does its parallelization capability perform in a real-world operating environment? Can it maintain sustainability amidst the expanding trends of RWA and financial applications? This research report will systematically analyze Pharos Network from multiple dimensions, including technical architecture, performance design, ecosystem landscape, and competitor analysis, to reveal its technological essence and strategic product considerations.
The author would like to remind you that the following content is merely an objective analysis of the formation characteristics and technical principles of Pharos Network, and does not constitute any proposal or offer. Please do not make any decisions based on this information. Furthermore, the RWA business involved in this project cannot be directly conducted in mainland China (it requires completion of compliant issuance procedures such as filing with the China Securities Regulatory Commission and cooperation with domestic and international entities). Please strictly abide by the laws and regulations of your country or region (readers in mainland China are strongly advised to read " A Summary and Key Points of Laws and Regulations Related to Blockchain and Virtual Currency in Mainland China "), and do not participate in any financial activities prohibited by the laws of your country or region.
background
Looking back at the development of blockchain technology, since the birth of the Bitcoin infrastructure network, blockchain has undergone multiple evolutions driven by different application needs and technological changes.
Early Bitcoin infrastructure networks were designed as "distributed ledgers," aiming to provide a decentralized method for value transfer and settlement. Therefore, they were not specifically optimized for high-frequency interactions or complex application scenarios. While Ethereum later expanded the "ledger" concept of blockchain to a "general-purpose computing platform," opening up more possibilities for on-chain applications, and next-generation public chains like Solana focused on high throughput performance to enhance network interaction capabilities, the architecture of these blockchains remains a monolithic paradigm. As the scale of on-chain interactions continues to grow, performance improvements gradually exhibit diminishing returns.
Subsequently, modular blockchain paradigms, represented by Celestia and Cosmos, began to emerge. Modular architecture decouples the consensus layer, data availability layer, settlement layer, and execution layer, allowing them to operate collaboratively in parallel. Specifically, the consensus layer is responsible for determining the order of transactions within a block and final confirmation, i.e., determining the order in which transactions in the mempool are included in which block; the data availability layer (DA layer) stores the data needed to verify the validity of transactions; the settlement layer verifies Rollup L2 state data and handles fraud/validity proofs; and the execution layer handles transaction and state updates.
This architecture, to some extent, breaks through the scalability bottleneck of monolithic blockchains, improving the system's flexibility and scalability. However, with the rise of narratives such as GameFi, on-chain payments, RWA, and AI, the market's requirements for blockchain performance are further shifting towards "commercial-grade real-time performance." For example, GameFi scenarios emphasize millisecond-level interaction latency and high-frequency state updates; on-chain payments require low-cost, highly deterministic, and rapid settlement; while RWA scenarios rely more on auditability and deterministic execution within a compliance framework. Consequently, a number of specialized blockchains targeting specific application needs have emerged, pursuing higher throughput, lower latency, and stronger determinism. From this point onward, blockchain technology has entered a new phase of performance competition.
Emerging narratives pose challenges and requirements to blockchain.
Compared to early distributed finance scenarios, emerging narratives such as high-frequency interaction, Real-Time Automation (RWA), and AI place more stringent demands on network throughput, confirmation latency, and execution determinism. In these scenarios, blockchain is no longer just a tool for asset transfer, but needs to assume a role closer to Web2 in terms of real-time interaction and commercial-grade infrastructure.
For example, in scenarios involving high-frequency interactions and automated execution of AI agents, the interactions are often not triggered manually by the user, but rather by the program initiating a large number of calls in a very short period of time. This requires the underlying network to have higher TPS and throughput limits, stronger concurrent processing capabilities, and lower confirmation times; otherwise, the needs of on-chain applications will be difficult to support.
When traditional public blockchains face network congestion, their interaction confirmation time often fluctuates significantly. This fluctuation has a limited impact on ordinary transfer scenarios, but it will have a significant amplified impact on applications that are highly sensitive to time windows, such as AI Agent collaboration, RWA clearing and settlement, and on-chain payments.
Furthermore, large-scale, high-frequency calls will lead to a continuous increase in on-chain state, further burdening the computational and storage load on network nodes. This means that blockchains geared towards emerging narratives not only need to improve network throughput but also require continuous optimization in multiple aspects, such as state storage structure and node resource utilization.
Moreover, in scenarios such as RWA and payments that target institutional users, blockchain often needs to provide stronger compliance interfaces, clearer boundaries of responsibility, and more stable execution rules to meet users' requirements for certainty, auditability, and risk control.
In other words, the challenges faced by dedicated blockchains for emerging narratives will no longer be just about TPS competition, but a comprehensive competition encompassing multiple dimensions such as system stability and compliance. This is also objectively driving the further reconstruction of the underlying architecture of blockchains.
Main Paths to Improve Blockchain Network Performance
The interaction process in blockchain is essentially a strict pipeline, where transactions need to go through processes such as sorting, confirmation, execution, state writing, and broadcasting in sequence. Generally speaking, the main paths to improve blockchain network performance include:
- Improving node hardware performance through increased computing power, bandwidth, and storage capacity enhances execution efficiency; Solana is a representative example of this approach. However, the decentralized nature of blockchain requires nodes to perform redundant verification and storage. Therefore, even if hardware upgrades improve the performance of individual nodes, the overall system will still face high resource consumption issues. Furthermore, hardware upgrades raise the barrier to entry for node participation, leading to a more centralized distribution of nodes.
- Moving from a monolithic to a modular approach to blockchain involves decoupling and optimizing different blockchain functions separately. This paradigm can effectively improve the flexibility and scalability of system design. However, the overall performance of blockchain is more like a "barrel," its capacity not depending on the longest plank, but on the shortest bottleneck. In other words, while modularity increases the upper limit of the capabilities of certain modules, it also creates new constraints on cross-module communication, data transmission, and overall collaboration costs.
- Extending the Rollup/L2 system to monolithic blockchains shifts execution pressure off-chain to alleviate pressure on the mainnet. This approach has been widely validated in the Ethereum ecosystem. However, as the Rollup/L2 system matures, it has created new bottlenecks, such as state bloat, data fragmentation, and liquidity disruption. These are precisely the potential challenges facing the Ethereum L2 ecosystem.
- Reconstructing the underlying network architecture involves redesigning the blockchain system from aspects such as execution models, storage structures, and verification methods to adapt to higher performance requirements. This approach often breaks through the constraints of traditional architectures, but it is technically more difficult to implement and requires a longer period of security verification and ecosystem integration. However, with the rapid development of Web3 technology, reconstructing the underlying network architecture may be becoming a new breakthrough direction.
Introduction to Pharos Network
Against this backdrop, Pharos Network is committed to building a high-performance, modular Layer 1 blockchain, with special optimizations for commercial and financial applications. Through modular architecture design and reconstruction of the underlying system, Pharos Network introduces parallelization technology in key areas such as consensus, execution, and storage, aiming to maximize the overall network throughput and scalability, reduce interaction latency and system costs, and thus drive the development of next-generation decentralized applications.
Pharos Network was founded in July 2024. In November of the same year, Pharos Network announced the completion of an $8 million seed round of financing led by Lightspeed Faction and Hack VC.
According to publicly available information , core members of the Pharos Network team, Wish Wu and Alex Zhang, both have experience working on Ant Group's Web3 project ZAN. Alex Zhang previously served as Chief Technology Officer at Ant Group Digital Technology Company and as head of the Blockchain Lab at Alibaba DAMO Academy. Therefore, the market generally believes that Pharos Network and Ant Group have a certain degree of cooperation in blockchain business. This is also reflected in the official announcement released by Yunfeng Financial when it invested in Pharos Network in September 2025. In that announcement, Yunfeng Financial explicitly mentioned that it had reached a strategic cooperation agreement with Ant Financial, and the two parties would jointly expand RWA and the next-generation Web3 development path in a compliant manner through Pharos Network.
In addition, in May 2025, Pharos Network announced a collaboration with AntChain to open-source DTVM (Deterministic Virtual Machine) to optimize virtual machines.
In terms of product progress, Pharos Network's public testnet went live in May 2025. In November of the same year, Pharos Network announced the establishment of the Pharos Foundation, aiming to further promote the healthy development of the Pharos ecosystem in a trustworthy, transparent, and compliant environment.
Parallelization bottleneck of traditional blockchain architecture
From a technical perspective, parallelization has become an important direction for improving blockchain performance. However, both modular and monolithic blockchains face certain technical bottlenecks in practical implementation.
From an overall architectural perspective, modular blockchain divides the system into different functional modules such as a consensus layer, execution layer, data availability layer, and settlement layer. These modules interact through standardized interfaces, and each layer can be independently optimized or replaced, which improves the system's flexibility and scalability to a certain extent.
However, in actual operation, cross-layer scheduling and data interaction between modules often introduce additional communication costs and a certain degree of synchronization delay. More importantly, since different modules are usually run by their own independent node networks, any work involving cross-layer verification and status confirmation often needs to be completed step by step in a predetermined order, making it difficult to achieve efficient parallel processing.
If we attempt to parallelize based on a monolithic blockchain architecture, we will also face a series of technical and hardware limitations.
First, the traditional EVM (Ethereum Virtual Machine) design dictates that it can only execute transactions sequentially in a single thread. This means that even though current server CPUs have long entered the multi-core era, the EVM struggles to actively invoke and coordinate multiple cores to execute transactions simultaneously. Therefore, the primary task of parallel EVM technology is to solve how to fully utilize the computing power of multi-core CPUs while ensuring state consistency.
Secondly, Ethereum uses the Merkle Patricia Trie (MPT) data structure to store information such as account states, contracts, and transactions, as well as to verify account states. In this structure, the hash value of each node is generated by the hashes of its child nodes. Modifying a leaf node requires recalculating the hash values of all parent nodes layer by layer upwards from that leaf node until the root node. Since leaf nodes store the state information of accounts on Ethereum, read-write conflicts occur when multiple transactions attempt to access or modify the same data in the state tree. This leads to another core problem that parallel EVM technology needs to solve: how to determine which transactions can be processed in parallel and which transactions need to be executed in the normal order. For example, Solana uses a Sealevel mechanism to determine in advance which accounts the system needs to access and operate on, and the Ethereum community is also introducing the BALS (Block-Level Access List) solution, attempting to allow validators to know in advance the account and contract information contained in each block.
Secondly, parallel execution introduces significant I/O bottlenecks. This is because when multiple transactions are executed concurrently, they often require frequent readings of smart contract code, account status, and other data from the hard drive. However, even the highest-performing solid-state drives (SSDs) currently available have random read and write speeds far slower than CPU computation speeds. This inherently slows down the efficiency of parallel computing, causing the CPU cores to spend most of their time waiting for data.
In addition, many current EVM chains employ optimistic execution mechanisms, meaning they execute first and then verify. In parallel operation, if a transaction conflict is discovered only during verification, the additional computational burden caused by rolling back the transaction will be substantial, potentially negating the performance gains from parallelization.
Therefore, to comprehensively improve the parallel efficiency of a blockchain system, it is necessary to address multiple dimensions such as storage, execution, hardware, and consensus.
Pharos Network Technical Architecture
To this end, Pharos Network attempts to achieve higher system throughput and better scalability by integrating multiple technical approaches to improve blockchain performance. Specifically, based on a modular protocol stack, Pharos Network has made targeted optimizations to core components such as consensus, execution, and storage, and further built a multi-network system with SPN (Specialized Processing Network) at its core.
In other words, the Pharos Network is a network composed of a mainnet and several SPNs. The mainnet itself is a blockchain with a complete modular protocol stack, primarily responsible for core functions such as network consensus, security, data availability, and final settlement. The SPNs, on the other hand, exist as dedicated network examples that rely on the mainnet security, acting as "on-chain coprocessors" and theoretically capable of unlimited expansion. SPNs are not limited to traditional blockchain forms, aiming to provide differentiated computing power support for different types of applications. They can be blockchain networks built for specific application scenarios, or dedicated computing networks providing GPU computing, AI inference, and data storage capabilities.
Therefore, the overall architecture of Pharos Network can be abstracted into three components: the mainnet, the SPN dedicated processing network, and the native restaking mechanism that enables the coordination of shared security and economic incentives.
Mainnet
Similar to conventional modular blockchain architectures, the Pharos Network mainnet protocol stack also includes several core components: a network communication layer, a consensus layer, an execution layer, a state storage layer, and a settlement layer. The network communication layer is responsible not only for P2P communication between nodes but also for cross-network message passing and interaction between the mainnet and SPN networks, aiming to maintain the coordinated operation of the entire multi-network system. The settlement layer is responsible for providing final confirmation of the global state and using a restaking mechanism to provide unified security for the mainnet and various SPNs.
Building upon this foundation, Pharos Network has focused on optimizing the consensus layer, execution layer, and state storage layer, providing underlying support for the introduction of parallelization capabilities. Specifically, at the consensus layer, Pharos Network employs an asynchronous BFT (Byzantine Fault Tolerance) mechanism to handle global interaction ordering, block confirmation, and the achievement of the system's final state. At the execution layer, Pharos Network introduces a dual virtual machine architecture, supporting both EVM and WasmVM execution environments to ensure compatibility with the existing Ethereum ecosystem and support for higher-performance applications. Furthermore, the execution layer incorporates optimistic mechanisms and pipeline finality design to achieve lower latency. At the storage layer, Pharos Network has restructured the state storage architecture, improving disk read/write efficiency and reducing long-term storage costs by optimizing the storage engine and state data organization.
Next, we will conduct a more in-depth breakdown and analysis of the above modules to further understand the key technical designs of Pharos Network in terms of performance and scalability.
consensus layer
Currently, many blockchains employ fixed-time slots in their consensus protocols, meaning a block is produced at fixed intervals. The advantage of this mechanism is a clear network rhythm, allowing nodes to work at a predictable pace. However, its disadvantage is that it limits the upper limit of network throughput. For example, if the network's fixed block production time is 10 seconds, but they can actually complete block propagation and consensus confirmation in just 5 seconds, then nodes are left idle for the remaining 5 seconds. This effectively wastes network resources and limits further increases in throughput.
Furthermore, in many networks based on the BFT (Byzantine Fault Tolerance) protocol, the consensus process typically involves first selecting a proposer who then constructs and broadcasts a block, after which other nodes vote on the block. While this single-proposer model is logically simple, it suffers from a scalability bottleneck: the proposer needs to broadcast the complete block to all other validator nodes, and the more validator nodes there are, the greater the proposer's broadcasting burden becomes. Simultaneously, when the proposer is handling a large amount of data uploading, the bandwidth resources of other nodes are often idle. The proposer's uplink bandwidth (i.e., the speed at which data is sent out) usually has a physical limit, which further restricts the block propagation speed, thus affecting the overall system throughput.
Therefore, Pharos Network addressed these two bottlenecks. On one hand, it adopted a strategy without fixed time assumptions; on the other hand, it allowed multiple validator nodes to propose blocks simultaneously within the same time window. This means that the Pharos Network does not pre-determine a fixed block production interval. Once a validator node completes transaction packaging, it can immediately broadcast its block proposal to the network; once the network achieves consensus confirmation, the block can be officially confirmed. This allows the system's block production speed to dynamically adapt to network conditions: when network latency is low and propagation efficiency is high, the block production speed can automatically increase; while when network congestion or increased latency occurs, the system will automatically slow down the block production pace to maintain consensus stability.
Meanwhile, multiple candidate blocks may exist in the network at the same time. As long as a block receives confirmation from a majority of validator nodes, it can become a valid block. The protocol will then sort and finally confirm the blocks. In this way, the uplink bandwidth of all validator nodes will be mobilized, thereby reducing the network bottleneck caused by the single proposer mode.
To support the above mechanism, Pharos Network introduced an asynchronous BFT consensus mechanism, allowing the protocol to operate without a predefined upper limit on message propagation time. This means that nodes can dynamically adjust their participation frequency based on their hardware capabilities and network conditions. For example, nodes with advanced hardware can produce blocks more frequently, while nodes with weaker performance can produce blocks less frequently. In this way, the network can accommodate a wider variety of participants while maintaining high performance.
Execution layer
If the consensus layer solves the problem of "whose block will be confirmed", then the execution layer solves the problem of "how to execute interactions within a block faster and ensure the determinism of the result".
To support high parallelism and fast confirmation capabilities, Pharos Network explicitly divides its execution architecture into two parts: the Scheduler and the Executor. The Scheduler is the core component for parallel scheduling and execution of transactions, responsible for analyzing dependencies between transactions and determining which transactions can be executed together and which must be executed sequentially. The Executor, on the other hand, is responsible for the actual execution of transactions. It operates through two engines: the EVM and WASM (WebAssembly), ensuring compatibility with the existing Ethereum ecosystem while supporting a higher-performance execution environment.
It should be noted that WASM was originally designed as a general virtual machine standard for web browsers. Its main goals are speed, efficiency and portability, not consistency. [1] That is to say, in some cases, the same code may produce slight computational differences when executed on different hardware architectures or in different operating environments. This is usually acceptable in web environments, but in blockchain systems, it may lead to different nodes producing inconsistent execution results for the same transaction, resulting in inconsistent states and even consensus disagreements. Therefore, Pharos Network does not use the standard WASM, but a modified deterministic virtual machine (DTVM) to ensure that the final execution results of smart contract code remain consistent when running on devices with different performance, types and bandwidths.
Returning to the execution layer architecture of the Pharos Network, in the scheduling process, the Pharos Network first analyzes the smart contract code to predict which states each transaction might read or write, and generates "parallel hints." If the read and write sets of two transactions do not overlap, they can be grouped into the same group for parallel execution; otherwise, they are grouped into different groups. During grouping, the Pharos Network maximizes the use of hardware resources; devices with more powerful CPUs will be allocated more data groups that can be executed simultaneously.
In its execution process, Pharos Network introduces an optimistic execution mechanism. Under this mechanism, the system first assumes that the parallel grouping during the scheduling phase is correct and executes transactions in parallel. If a state conflict is found between transactions during execution, only the conflicting transactions are rolled back and re-executed, without recalculating the entire transaction set, which helps to reduce the performance loss caused by transaction conflicts.
During the result confirmation phase, Pharos Network employs a pipeline finality mechanism to pursue lower latency execution, thus addressing the biggest bottleneck in improving transaction execution efficiency.
Unlike the traditional blockchain process of transaction sorting -> transaction execution -> transaction consensus -> final confirmation -> user sees the result, Pharos Network optimizes the process to: transaction sorting -> scheduler groups transactions -> executor executes transactions -> user sees execution result in advance -> block finality is achieved. In other words, in Pharos Network, transaction execution results can be observed by users before the block reaches final confirmation, while the finality of the block is completed by the subsequent consensus process. This is because final confirmation of a block requires network-wide consensus, while transaction execution results can be generated in advance during the local execution phase.
Generally, a good pipeline execution architecture needs to overcome the following key issues:
- If the balance of the same account differs at different block heights, how can we ensure the correctness of the execution results and avoid conflicts when multiple threads read and write simultaneously?
- How to improve hard drive read and write speeds to enhance the overall parallel efficiency of the system;
- How to balance and allocate the CPU and storage resources required at each stage of the pipeline;
- How to fill the time gap when blocks are waiting for final confirmation from the consensus layer.
To address the above issues, Pharos Network has made improvements in three areas:
1. Allow different blocks at different stages to run in parallel: For example, suppose block 1 is currently in the execution stage, block 2 can enter the consensus stage, and block 3 may be in the network propagation stage. They can run simultaneously without affecting each other.
2. Optimize dynamic resource allocation: Dynamically allocate system resources according to the different stages of different blocks. For example, blocks in the execution stage require more CPU resources, blocks in the consensus stage require more bandwidth resources, and blocks in the state writing stage require more storage I/O resources.
3. Flexibility in Achieving Finality: Because the Pharos Network operates in parallel, its finality actually encompasses both transaction finality and block finality. For ordinary users, they only care about the interaction result; therefore, once the transaction is executed and recorded by the system, the interaction is generally considered complete. However, for infrastructure such as oracles and indexers, they are more concerned with whether the block has achieved finality. Block finality means that the interaction result has been finally confirmed by the network and will not be rolled back. In other words, Pharos can achieve more efficient resource allocation and faster confirmation based on the different finality requirements of the SDK, clients, and nodes.
storage layer
Pharos Network has also restructured the state storage layer to address the state bloat and storage performance bottlenecks that are common in current blockchains, thereby improving storage performance and reducing storage costs, and providing underlying support for the parallel execution layer.
It is important to clarify that when a blockchain executes a smart contract, it is essentially constantly reading and modifying the state.
Taking Ethereum as an example, its network uses three Merkle trees to record: the state of all accounts in the entire Ethereum system (global state tree), the transactions contained in the current block (transaction tree), and the results of the transactions in the block after execution (receipt tree).
Therefore, when Ethereum network nodes execute transactions, they need to continuously read the state from these trees, perform modifications, and then update the tree structure. Each transaction generates a large amount of data reading, writing, and hash calculations, all of which ultimately need to be stored on the node's hard drive. When a node processes subsequent transactions, it needs to repeat this process: reading data from the hard drive, performing operations, and then writing new data to the hard drive.
This means that the complete path from "reading the state" to "updating the state" actually involves two layers of architecture: an upper Merkle tree (responsible for verifiability) and a lower disk storage (responsible for persistence). Every state access traverses these two layers, resulting in a long access path and additional I/O latency. Meanwhile, as the blockchain continues to operate and state data accumulates, state bloat occurs, further increasing storage costs and access latency.
To address this, Pharos Network launched Pharos Store, a completely new storage system.
First, Pharos Store embeds the Authenticated Data Structure (ADS) within the storage engine. Simply put, Pharos Store directly integrates the Merkle tree into the underlying storage layer, merging the two into one and significantly shortening the I/O path. Simultaneously, Pharos Store is designed to be compatible with various Merkle tree structures, including MPT, JMT, and ZKTrie.
Secondly, Pharos Store changes the storage method of Merkle trees, replacing traditional hash addressing with version-based sequential storage. In traditional Merkle trees, the data storage location is determined by the content hash, resulting in data being randomly distributed on the hard drive and unable to be read sequentially. Pharos Store, however, requires each data node to record the block height corresponding to the data during storage. In this way, data can be stored sequentially according to block height, and external access to the hard drive can utilize this continuity to achieve batch preloading, thereby significantly improving the read and write efficiency of the hard drive.
Furthermore, Pharos Store has optimized the process of saving Merkle tree nodes to disk. On the one hand, when saving a node, Pharos Store only records the data that has changed, instead of rewriting the entire node to disk every time. This significantly reduces the amount of writing during each state update. On the other hand, Pharos Store optimizes the way data is organized so that a single disk read operation can access multiple nodes simultaneously, thereby significantly reducing the number of I/O operations required to access multiple nodes. With these optimizations, under the same hardware conditions, Pharos Store can handle more than 15 times the number of interactions of traditional solutions, while the cost of storing the same data is reduced to 1/5 of the original. [2]
SPN
In traditional blockchain architectures, different types of applications often need to share the same execution environment and resources. While this model is simple in structure, it limits the system's scalability to some extent and makes it difficult to perform in-depth optimization for specific scenarios. To address this issue, Pharos Network introduced the SPN (Special Processing Network) architecture, attempting to break the limitation of a single execution environment by building a dedicated computing network for specific application scenarios, enabling different types of applications to run in a more suitable operating environment.
However, due to the differences in application goals and computational requirements of various SPNs, their network architectures also exhibit high flexibility. For example, AI applications typically rely more on high-performance computing resources such as GPUs, distributed financial applications emphasize low latency and high throughput transaction processing capabilities, while zero-knowledge proof (ZK) applications require support for high-intensity proof generation and verification computations.
Therefore, unlike the mainnet, SPN does not need to adopt a unified consensus mechanism, but can be customized according to its own needs. For example, to improve the openness and decentralization of the network, some networks may adopt the PoS (Proof of Stake) mechanism, enabling more nodes to participate in network verification through staking; for scenarios that emphasize deployment and operational efficiency, the PoA (Proof of Authority) mechanism can be chosen, with pre-determined validators responsible for block production; and for environments with high requirements for system stability and fault tolerance, PBFT (Practical Byzantine Fault Tolerance) or its improved consensus algorithms may be adopted.
In addition, another significant advantage of the SPN architecture lies in its support for heterogeneous computing. Developers can choose the most suitable hardware environment based on the application scenario to fully leverage the advantages of different types of computing resources. For example, GPUs can be used for massively parallel computing, TEEs (Trusted Execution Environments) can be used for privacy-preserving computations, and ZK accelerators can be used to generate zero-knowledge proofs. Through this approach, different SPNs can utilize underlying computing resources more efficiently, enabling the system to achieve better performance for different task types.
Cross-network communication between the mainnet and SPN
Pharos Network designed three types of nodes for its network: Validator Nodes, Full Nodes, and Relayer Nodes.
Among them, the validator node (which needs to stake a certain amount of assets to the network first) is responsible for running the PoS consensus protocol based on the BFT mechanism, and is responsible for proposing, voting, producing and finally confirming blocks. It is a core participant in network security and consistency.
Full nodes do not directly participate in consensus voting, but they are responsible for storing complete block data and the complete execution state. They also need to provide critical data infrastructure support for the network, including state synchronization, historical data querying, and providing validator nodes with execution scheduling hints, including transaction dependencies or information that can be executed in parallel.
Relay nodes, on the other hand, are lightweight nodes. They do not store complete historical data; they are only responsible for storing the latest state and processing recent transactions. Their main responsibilities include transaction forwarding, message routing, and message transmission between SPN networks.
To ensure stable interaction between SPNs and the Pharos Network mainnet, a cross-network communication mechanism is designed. When a user initiates an interaction or request on an SPN network, the relay node submits the relevant interaction information and necessary proofs to the Pharos Mainnet, which verifies and records the information. Subsequently, the target SPN can read these messages from the mainnet and execute corresponding operations, thereby enabling data and information flow between different SPNs and the mainnet.
Re-pledge mechanism
In terms of security mechanisms, to avoid each SPN needing to independently establish a complete validator system, Pharos Network introduced a native restaking mechanism similar to EigenLayer. Mainnet validators receive corresponding staking credentials while staking native tokens to participate in mainnet security. These credentials can be further restaking on different SPNs, thus providing additional security for the SPNs.
In this way, SPNs can inherit the mainnet's security and economic incentive system to a certain extent. However, if an SPN exhibits malicious behavior or malfunctions, the corresponding resold assets may also face penalties (slashing), thus creating economic constraints on the behavior of validator nodes.
summary
Overall, Pharos Network attempts to achieve parallel design for a full-stack architecture through a series of underlying technical optimizations. To better measure the parallel processing capability of a blockchain system, Pharos Network proposes the concept of Degree of Parallelism (DP), which describes the ability of a blockchain network to simultaneously utilize computing and data resources for parallel processing. Theoretically, the higher the degree of parallelism, the greater the number of interactions the system can process per unit of time.
According to official disclosures, Pharos Network has achieved DP5-level parallelism, specifically in the following aspects:
- By optimizing the block propagation protocol and consensus mechanism, an entry point is opened for the influx of massive transactions;
- By enhancing parallel execution capabilities, conflict-free transactions can be executed simultaneously on multi-core CPUs;
- By using a pipelined architecture to split and process transactions, the CPU is not idle while waiting for hard disk read/write operations, thus allowing transactions to be continuously added and processed.
- By implementing a parallel Merkel-optimized storage solution, hard disk I/O bottlenecks can be alleviated;
- By introducing external hardware such as GPUs and FPGAs, the system can be equipped with heterogeneous computing capabilities, thereby achieving more efficient resource allocation.
Pharos Network's ecosystem layout
To incentivize the development of its ecosystem projects, Pharos Network launched a $20 million ecosystem incentive program on March 7, 2025. This program is primarily open to project teams with innovative ideas and practical implementation capabilities, who have already made some progress in development. Key areas of support include RWA, payments, distributed finance protocols, DeAI, DeSci (decentralized science), and GameFi.
With the official establishment of the Pharos Foundation in November 2025, the responsibilities related to ecological fund management and project funding will formally transition to the foundation system. As a non-profit organization, the Pharos Foundation will be responsible for ecological funding, as well as supporting technological research and development, ecological governance, and ecological promotion, among other functions.
Within this framework, the foundation further launched the $10 million Pharos Builder Incubator Program. This program can be seen as a continuation of the previous ecosystem incentive program, primarily targeting project teams in the areas of RWA, payments, distributed finance, and innovative infrastructure.
However, according to Chainwire , details regarding the management and use of funds for the Pharos Ecosystem Fund will be disclosed in the first transparency report after the mainnet launch (expected in early 2026).
According to the official ecosystem map (statistics date: 2026/1/1), Pharos' current ecosystem projects are mainly concentrated in areas such as distributed financial protocols and infrastructure, and RWA applications.
The author would like to remind readers that the projects or agreements shown in the figures are for industry research purposes only and do not constitute any form of recommendation, investment advice, or endorsement of value. The relevant projects and technologies are still under development and may be affected by regulatory policies in different regions. Readers are advised to view these information rationally and strictly abide by the laws and regulations of their country or region, and not to participate in any illegal financial activities prohibited by law.
In addition, to better promote the development of the developer ecosystem and expand the adoption of the DTVM virtual machine, Pharos Networks has open-sourced its DTVM virtual machine. By making the core code public, developers can gain a deeper understanding of the technical implementation of DTVM and build upon it for further development and optimization.
In fact, the DTVM virtual machine was not developed independently by Pharos Network, but rather jointly with AntChain and Ant Super Computing (Ant Group's basic software and infrastructure team). Therefore, this virtual machine system can also be seen as an extension of Ant Group's technological accumulation in the fields of high-performance computing and blockchain infrastructure.
In addition, in order to further promote ecosystem cooperation and improve RWA-related infrastructure, Pharos Network announced the launch of the RealFi Alliance in February this year. The alliance aims to unite different market participants to build a unified collaboration framework for RWA scenarios in the Pharos ecosystem, so as to alleviate the infrastructure fragmentation and compliance issues that are common in the current RWA development process. [3]
Based on publicly disclosed information, the alliance's participants encompass a wide range of entities, including RWA assetization platforms, oracle infrastructure, liquid staking protocol, cross-chain transfer protocols, venture capital firms specializing in distributed finance, and digital asset wallets for RWA scenarios. These participants cover multiple key aspects, from asset issuance, data and oracle services, cross-chain interoperability, asset custody, wallets, to application-layer protocols. By integrating these infrastructure and application capabilities, Pharos Network is attempting to build a relatively complete on-chain financial ecosystem to propel RWA from a fragmented pilot phase towards a scalable on-chain financial system.
The author would like to remind readers that the projects or agreements shown in the figures are for industry research purposes only and do not constitute any form of recommendation, investment advice, or endorsement of value. The relevant projects and technologies are still under development and may be affected by regulatory policies in different regions. Readers are advised to view these information rationally and strictly abide by the laws and regulations of their country or region, and not to participate in any illegal financial activities prohibited by law.
Competitive analysis of Pharos Network
Looking at the development trend of blockchain infrastructure, infrastructure focused on commercial and financial applications is gradually emerging. Generally speaking, these projects can be roughly divided into two categories.
The first category comprises proprietary blockchains driven by leading institutions or stablecoin issuers. Examples include Plasma and Stable, backed by Tether; Arc, driven by Circle; and Ondo Chain, launched by Ondo Finance. These blockchains typically focus on stablecoin settlement, RWA issuance, and payment networks, with a strong emphasis on network performance, compliance, and financial-grade security in their design. In terms of governance, they are often dominated by specific institutions or consortia, exhibiting a relatively centralized governance structure. Overall, these blockchains represent a strategic deployment by leading institutions in the RWA and payment sectors.
The second category consists of general-purpose infrastructure designed for broader financial applications. Pharos Network and Plume Network can be considered representative of this type.
Plume Network is an EVM-compatible Layer 1 public blockchain, with its core positioning as RWAfi (RWA + DeFi) infrastructure. The project aims to bring traditional financial assets onto the blockchain and enable them to directly participate in activities within the distributed finance ecosystem. To this end, Plume Network has built a series of supporting tools and infrastructure, including the Financial Interaction System (ATS), the RWA no-code issuance platform, the cross-chain interoperability solution Plume SkyLink, and the smart wallet Plume Passport.
Compared to Plume Network, Pharos Network places greater emphasis on versatility. While Pharos also focuses on RWA-related applications, it does not limit its ecosystem to RWA assets themselves. Instead, it aims to provide a unified underlying infrastructure for distributed finance, payments, AI, and other application scenarios through high-performance execution architecture and parallel processing capabilities.
However, from a technical architecture perspective, there are also quite a few blockchain projects that emphasize high performance as their core selling point. For example, Sei is one of the more watched projects in this field right now.
Similar to Pharos Network, Sei also systematically optimized the consensus layer, execution layer, and state storage layer to improve overall throughput. However, they chose different technical solutions for parallelization implementation.
In terms of consensus layer, Sei still uses the BFT-based voting mechanism: first, the network selects block proposers and packages a batch of transactions into candidate blocks; then, all validators conduct pre-voting, and when a candidate block receives more than 2/3 of the weight support in the pre-voting stage, it enters the formal voting stage to complete the block confirmation.
At the storage layer, Sei optimizes the underlying state storage structure and database performance, and reconstructs the data read and write path to alleviate the read and write pressure caused by high-frequency state updates and reduce system latency during state writing.
Therefore, from the perspective of high-performance infrastructure, Sei and Pharos Network have some overlap in their target positioning, as both attempt to serve on-chain application scenarios with higher performance requirements through underlying architecture optimization.
Potential challenges faced by Pharos Network
Although Pharos Network has put forward a relatively clear development direction in terms of technical architecture and its focus on commercial and financial-grade infrastructure, from the current industry environment, in addition to the fierce market competition it is facing, Pharos Network still needs to deal with many potential challenges.
First, as mentioned earlier, while Sei and Pharos Networks differ in their technical implementation paths, both opted for a "dual virtual machine" architecture at the execution layer. However, starting in 2025, the Sei community began discussing whether to shift from a "CosmWasm + EVM" architecture to an "EVM-Only" architecture. This adjustment reflects both the team's product strategy and the technical complexity and cost pressures associated with developing and maintaining multi-virtual machine architectures. As a proponent of dual-virtual machine architecture, whether Pharos Networks can balance ecosystem compatibility with maintaining low development and maintenance costs is a question the team may need to consider beforehand.
Secondly, from an ecosystem development perspective, ecosystem size is typically a key indicator of blockchain platform adoption. Compared to Sei, which has already launched mainnet and established a certain ecosystem, Pharos Network is currently still in the test network phase, and its overall ecosystem is still in its early stages of development. Therefore, in the near future, Pharos Network needs to accelerate the development of its developer ecosystem and attract more practical applications to further validate the stability of its technical architecture.
Furthermore, although the Pharos Foundation stated in its ecosystem incentive program that it would support emerging application areas including AI and DeSci, the currently published ecosystem map shows that Pharos ecosystem projects are mainly concentrated in distributed finance, infrastructure, and RWA-related fields, with no applications such as AI that have attracted much market attention yet. This means that Pharos Network still has considerable room for ecosystem expansion in emerging sectors, and its ability to attract more types of applications to its ecosystem will be a crucial factor in whether it can achieve rapid expansion.
Meanwhile, although Real-World Asset Payments (RWA) and on-chain payments are widely regarded as one of the most talked-about narratives in the current market, their overall compliance systems are still in a stage of continuous exploration and improvement. RWA, in particular, focuses on mapping real-world assets onto the blockchain. This process often involves multiple stages, including asset issuance, custody, interaction, and cross-border capital flows, and therefore inevitably faces strict restrictions from the financial regulatory frameworks of various countries. As the scope of its products and services expands in the future, Pharos Network will need to provide solutions to the differentiated regulatory requirements in different jurisdictions. This requires Pharos Network to continuously advance its product development while constantly monitoring changes in industry policy and making timely adjustments.
Future Outlook
From the perspective of the overall industry development trend, the competition among blockchain infrastructures in the future may no longer revolve solely around the "degree of decentralization" or "general computing power," but will place greater emphasis on the performance, system stability, and ecosystem collaboration capabilities of blockchain in specific application scenarios.
Pharos Network's technical approach emphasizes high performance and parallel processing capabilities, which theoretically helps support application scenarios such as high-frequency interactions, payment settlements, and high concurrency demands. However, technical performance advantages alone are insufficient to guarantee the network's long-term competitiveness. How to transform the underlying infrastructure capabilities into real and sustainable application requirements, and on this basis, form a developer and application ecosystem, is a crucial challenge that Pharos Network will face in its future development. Furthermore, the development of financial sectors such as RWA and payments is still in its early stages. Although they have attracted significant market attention, large-scale deployment still depends on a sound regulatory framework, increased institutional participation, and mature asset issuance and custody mechanisms. This path is destined to be challenging.
Against this backdrop, whether Pharos Network can seize the market window and establish a differentiated position in the new round of competition for blockchain infrastructure depends not only on its innovative technical architecture, but also on its ability to achieve a long-term sustainable balance between "decentralization," "application coverage," and "institutional compliance requirements."
References
[1] What is the WebAssembly virtual machine? Why should we use it?
[2] Pharos Store
[3] https://x.com/pharos_network/status/2026114895264333984
[4] A Comprehensive Technical Deep Dive into Pharos Network Architecture
[6] FAQ - WebAssembly Chinese Website
Disclaimer: As a blockchain information platform, the articles published on this site represent only the personal views of the authors and guests and do not reflect the position of Web3Caff. The information contained in the articles is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.
Welcome to the official Web3Caff community : Twitter account | Web3Caff Research Twitter account | WeChat reader group | WeChat official account
