# I. Outlook

## 1. Macroeconomic Summary and Future Predictions

In May, the U.S. labor market showed resilience, with job openings continuing to increase and the unemployment rate remaining stable. However, the decline in labor force participation rate and employment-to-population ratio, along with a slowdown in job growth and reductions in positions in certain industries, indicate signs of economic softening.

The market is highly focused on the upcoming Consumer Price Index (CPI) data for May, which will be released on June 11. It is expected that the year-on-year CPI for May will rise from 2.3% in April to 2.5%, while the core CPI is anticipated to increase from 2.8% to 2.9%, reflecting the impact of tariff policies on prices.

## 2. Market Movements and Warnings in the Crypto Industry

Last week, the overall crypto market remained volatile, with major cryptocurrencies experiencing slight increases and low market activity. Macroeconomic uncertainties, trade policies, and regulatory risks continue to be the main warning factors for the market. Investors should pay attention to the global economic situation and policy dynamics, remaining vigilant against potential price fluctuations and liquidity risks. Institutional buying behavior provides some support for the market, but market sentiment remains cautious in the short term.

## 3. Industry and Sector Hotspots

The BTC native liquidity protocol Taker, which uses a brand new consensus mechanism called "NPOL," continuously incentivizes LPs through its own Taker Chain and releases BTC value. Having raised over $15 million, the sovereign protocol Analog, built on a DPoS consensus mechanism, achieves seamless communication and data exchange between dAPPs by adopting a full-chain structure.

# II. Market Hotspot Sectors and Potential Projects of the Week

## 1. Performance of Potential Sectors

1.1. Analyzing How Taker, a BTC Native Liquidity Protocol Using the New Consensus Mechanism "NPOL," Continuously Incentivizes LPs and Releases BTC Value Through Its Own Taker Chain

Taker is a Bitcoin-native liquidity protocol aimed at unlocking the utility value of BTC in decentralized finance (DeFi). The protocol is built on its own blockchain, Taker Chain, and employs an innovative consensus mechanism known as "Nominated Proof-of-Liquidity" (NPOL), which maintains network security and operation by rewarding liquidity providers.

The platform allows users to bridge BTC and BRC-20 assets (such as Ordi, Sats) from the Bitcoin chain or Ethereum chain to Taker Chain through a secure cross-chain bridge called "Dynamic Hidden Committee" (DHC). Once bridged, users can stake LP tokens, participate in governance through veTAKER, and earn rewards from transaction fees and block rewards.

Taker has also launched Taker Swap, a native decentralized exchange (DEX) based on an automated market maker (AMM) mechanism, optimized for capital efficiency and low slippage trading.

++Architecture Overview++

Taker enhances your Bitcoin yield through the NPOL (Nominated Proof-of-Liquidity) consensus mechanism, closely aligning liquidity provision incentives with ecosystem growth, forming a symbiotic yield model. To promote the development of the Bitcoin ecosystem, Taker is committed to unlocking long-dormant BTC liquidity, bringing significant potential.

At the same time, Taker will provide ample liquidity for various scenarios, including Layer2, native swaps, restaking, lending, gaming, and more. Taker will become a blockchain that supports early users staking LP tokens (such as BTC/Ordi, BTC/Sats, BTC/WBTC, BTC/BTCB, BTC/USDT, BTC/USDC, BTC/ETH, etc.), allowing users to enjoy returns from liquidity provision and Taker Chain block rewards by becoming validators or nominators.

User Process:

1. Users can securely bridge their BTC and BRC-20 assets (such as Ordi, Sats, USDT) from the Bitcoin main chain to Taker Chain through our cross-chain bridge built on DHC technology.

2. By staking LP tokens and locking them, users will receive veTAKER as a reward.

3. Users can choose to stake veTAKER to become validators or nominators.

4. Block rewards (including veTAKER and TAKER) will be distributed to validators and nominators based on the amount and weight of their stakes in the network.

5. ++What is NPOL (Nominated Proof-of-Liquidity)?++ The NPOL consensus mechanism aims to establish a secure, efficient, and fair blockchain network by integrating the advantages of NPOS (Nominated Proof-of-Stake) and POL (Proof-of-Liquidity). It combines the nomination and voting system of NPOS with the liquidity incentive mechanism of POL to construct a robust consensus model.

Core Components of NPOL Consensus:

NPOS Layer:

• Stakeholders:
  Token holders (nominators) stake their tokens to participate in the network.
• Nomination Mechanism:
  Nominators propose validators responsible for block production and transaction validation.
• Election Mechanism:
  A group of validators is elected to participate in consensus based on the voting weight of nominations.

POL Layer:

• Liquidity Staking:
  Validators stake liquidity tokens (such as TAKER) to demonstrate their commitment to network stability.
• Liquidity Rewards:
  Validators receive rewards based on the liquidity they provide, incentivizing them to maintain sufficient liquidity.
• Liquidity Sources:
  Liquidity can come from exchanges, liquidity pools, or other DeFi protocols.

Synergistic Advantages of NPOL Consensus:

Enhanced Security:

• The voting system of NPOS distributes validation power among multiple stakeholders, reducing the risks of centralization and malicious attacks.
• The liquidity incentive mechanism of POL encourages validators to maintain network stability, improving resilience against potential disruptions.

Improved Scalability:

• The efficient validator election mechanism of NPOS helps accelerate block production and increase transaction throughput.
• POL's focus on liquidity ensures that the network maintains performance while handling a growing volume of transactions.

Promoting Fairness:

• The open nomination and voting system of NPOS allows all token holders to participate in the consensus process.
• The reward distribution mechanism of POL incentivizes validators to provide liquidity, benefiting all users in the network.

1. ++Validators++ Validators are the backbone of the NPOL consensus mechanism, playing a key role in maintaining network security, validating transactions, providing liquidity, and ensuring overall network stability. They are responsible for producing blocks and validating them, thus safeguarding the integrity of the blockchain ledger.

Core Responsibilities of Validators in NPOL:

Block Production:

• Validators are responsible for creating new blocks, packaging valid transactions, and adding them to the blockchain.
• As a reward for block production, validators receive corresponding transaction fees.

Transaction Validation:

• Validators must verify the validity of transactions before they are written into blocks.
• This includes checking that signatures are correct, account balances are sufficient, and transactions comply with network rules.

Liquidity Provision:

• In addition to block production and transaction validation, validators in the NPOL system must also stake liquidity tokens.
• This mechanism incentivizes validators to maintain sufficient liquidity within the network, ensuring users can smoothly trade and exchange assets.

1. ++Nominators++ Nominators are indispensable participants in the NPOL consensus mechanism, playing an important role in validator elections, network governance, and overall network health. Their actions help enhance the security, decentralization, and fairness of the NPOL ecosystem.

Core Responsibilities of Nominators in NPOL:

Validator Elections:

• Nominators recommend validators they believe are capable and trustworthy to participate in the consensus mechanism.
• They support their nominations by staking tokens, indicating trust in the proposed validators.

Voting Weight:

• Each nominator's voting weight is proportional to the number of tokens they have staked.
• These votes determine which validators will be selected to participate in the consensus process.

Network Participation:

• Nominators contribute to the decentralization and security of the network by actively participating in the validator election process.
• Their actions help ensure that the network is governed by a diverse set of stakeholders.

++Ecosystem Projects++

Taker Swap Taker Swap is the native decentralized trading protocol (DEX) of Taker Chain, designed to maintain liquidity within the Taker ecosystem through liquidity pools in an automated market maker (AMM) mechanism. Taker Swap operates by allowing users to deposit crypto assets into liquidity pools to provide liquidity for trading, with the system algorithmically setting token prices based on the proportion of assets in the pool. Users can directly swap one token for another through AMM during trading. The design of Taker Swap is inspired by the innovative mechanisms of Uniswap V3.

Key Features:

• Concentrated Liquidity allows individual liquidity providers (LPs) to finely control the price distribution of their funds. This precise targeting significantly enhances capital efficiency, as liquidity is concentrated in the most needed price ranges.
• Multiple Fee Tiers allow LPs to receive corresponding compensation based on the level of risk they undertake, enhancing the flexibility and fairness of participation incentives.
• Reduced Gas Costs optimized contract design lowers gas consumption in transactions, making Taker Swap more economical, efficient, and attractive for traders.
• High Capital Efficiency achieves low-slippage trading execution, with the potential to surpass centralized exchanges and AMM platforms focused on stablecoin trading.
• Lower Capital Risks LPs can significantly increase their holdings of preferred assets while reducing downside risks, enhancing the flexibility of capital utilization.
• More Operation Capacity LPs can achieve a "fee-earning limit order" effect by adding liquidity within specific price ranges above or below the current market price, smoothing transactions along the price curve.
• Permissionless Pool and Extra Rewards Taker Swap supports standard permissionless liquidity pools, allowing any user to freely add, remove, or swap liquidity without restrictions. However, only supported asset pools (such as BTC/WBTC, BTC/BTCB, BTC/USDT, BTC/USDC, BTC/Ordi) can earn additional veTAKER rewards.

++Comments++

As a Bitcoin-native liquidity protocol, Taker has significant advantages: its innovative NPOL consensus mechanism integrates staking and liquidity incentives, enhancing network security and capital efficiency; it releases BTC liquidity through components like Taker Swap, bridging DeFi scenarios; and it supports a rich variety of asset pairs and flexible LP strategies, providing users with stable returns and opportunities to participate in governance. However, its disadvantages cannot be ignored, such as requiring users to operate across chains, high learning costs, initial ecosystem and liquidity construction relying heavily on operational support, and facing market competition and security challenges as a new chain.

1.2. Analyzing How Analog, a Sovereign Protocol Built on DPoS Consensus Mechanism That Raised Over $15 Million, Achieves Seamless Communication and Data Exchange Between dAPPs by Adopting a Full-Chain Structure

Analog is a sovereign blockchain aimed at promoting the development of the next generation of decentralized ecosystems. As a network centered on interoperability, Analog connects disparate blockchains by addressing cross-chain communication and liquidity challenges. Analog is committed to bridging traditional finance (TradFi) and Web3, enabling developers to build decentralized applications (dApps) that span across chain boundaries.

++Architecture Overview++

The Analog tech stack consists of the following components, all designed to break down the barriers faced by dApp development and cross-chain communication in a multi-chain environment, as shown in the diagram below:

• Timechain: A nominated proof-of-stake (NPoS) protocol maintained by a dynamic and decentralized set of validators. Timechain serves as the core ledger and accountability layer of the Analog network. In addition to coordinating cross-chain activities, Timechain also has a built-in execution environment for Solidity-based smart contracts. For more details, see Timechain EVM.
• SDKs: User-friendly and pluggable toolkits running on Timechain. Currently, two products operating on Timechain are Analog Watch, which provides developers with seamless access to blockchain data; and Analog GMP, which supports cross-chain smart contract execution calls.
• Unified API: A unified GraphQL API that provides an out-of-the-box developer experience, allowing developers to seamlessly and scalably query smart contracts on any supported chain.

The core concept of Analog is often referred to as a "decentralized liquidity network," utilizing Timechain to manage interactions with external blockchains. Timechain employs multi-party computation (MPC), particularly threshold signature schemes (TSS), to generate aggregated keys (i.e., TSS keys).

These keys are distributed across a permissionless sharded network, which controls gateway smart contracts connecting the blockchains. The "accounting layer" built on a Substrate-based blockchain works in conjunction with these shards to track activities, process events, and facilitate message execution across all supported blockchains, thereby creating a fully decentralized universal liquidity network.

Analog utilizes a hub-and-spoke model, with Timechain serving as the central hub connecting multiple blockchains. This centralized structure simplifies cross-chain communication by reducing complexity and enhancing security. All messages and data are routed through Timechain, making integration and scaling simpler as chains increase.

++Shards++

To enhance scalability, Analog divides the network into multiple shards. Shards are sub-networks/clusters composed of Chronicle nodes (validators) that collectively manage cryptographic operations. Each shard operates semi-autonomously, with its nodes collaborating to generate cryptographic keys to ensure security.

Shards play a key role in improving network scalability and efficiency:

• Task Allocation: Shards enable the network to allocate tasks to smaller groups of Chronicle nodes, achieving parallel processing.
• Specialized Functions: Different shards can be assigned to execute specific roles or types of tasks.
• Increased Throughput: By distributing workloads, shards enhance overall transaction processing capacity.
• Enhanced Security: Shards employ threshold cryptography, requiring a minimum number of members to execute operations, thus improving security and fault tolerance.

The lifecycle of a shard primarily includes the following stages:

• Creation Stage:
• Administrators create shards, specifying members and thresholds (the supermajority required to execute cross-chain operations).
• Members initialize distributed key generation (DKG).
• Setup must be completed before timeout.
• Commitment Stage:
• Members submit cryptographic commitments.
• When the threshold is reached, a group public key is aggregated.
• Preparation Stage:
• Members confirm that operations are ready.
• Once all preparations are complete, the shard goes live.
• Operating Stage:
• Processing network tasks (e.g., monitoring and parsing inbound transactions from external chain gateways for processing on Timechain).
• Monitoring member availability.
• When member availability falls below the threshold, the shard goes offline.
• Fault Handling:
• Timeouts trigger automatically.
• Manual intervention by administrators.
• Trigger member reassignment.

++Gateways++

The foundation of cross-chain communication is the contracts managed by shards on each supported chain. Gateways are smart contracts managed by shards for each Timechain interaction with supported blockchains.

Regardless of the specific implementation, gateway contracts ultimately create accounts controlled by shards across various blockchains, establishing a decentralized and universal liquidity management layer.

++Accountability Layer++

In addition to coordinating interactions between different blockchains, Timechain also serves as the foundational accountability layer for the entire Analog ecosystem. While Chronicle nodes use multi-party computation (MPC) to manage communication with connected blockchains, accountability functions are handled by Time nodes.

These Time nodes maintain and update Timechain through the NPoS consensus mechanism, including block production and executing external transactions (extrinsics), ensuring that all activities have transparent and verifiable records.

Some accountability events managed by Timechain include:

• Registration and Tracking of Validators
• Registration and Management of Shards via Key Rotation
• Assigning Shards to Chronicle Nodes
• Initiating Tasks on Target Shards to Trigger Cross-Chain Request Execution
• Staking and Penalty Mechanisms
• Governance Mechanisms

++Summary++

Analog's advantages lie in its decentralized liquidity network built around Timechain, achieving efficient cross-chain communication and data exchange through multi-party computation (MPC) and sharding architecture, with good scalability, security, and cross-chain compatibility, making it particularly suitable for building Web3 applications in a multi-chain environment. Meanwhile, the unified GraphQL API and user-friendly SDK tools lower the development threshold, supporting rapid deployment of dApps. Its disadvantages include a complex overall architecture, high implementation barriers, and reliance on MPC, TSS, and distributed key management, which may pose performance and stability challenges. Additionally, there is pressure in the early stages to build the ecosystem and attract developers.

## 2. Detailed Analysis of Projects to Watch This Week

2.1. Detailed Analysis of How Acurast, the First Decentralized Verifiable Computing Network Driven by Smartphones, Utilizes Trusted Execution Environments (TEE) and Hardware Security Modules (HSM) to Transform Mobile Devices into Computing Nodes

++Introduction++

In today's highly interconnected world, centralized trust is pervasive, from computing resources to data storage and their underlying infrastructure. The monopoly of cloud computing resembles a feudal system, leading to loss of privacy and data ownership.

Cloud computing and the entire internet face the following recognized challenges:

• Centralized trust in auxiliary systems (such as centralized cloud service providers);
• Seamless, permissionless interoperability between fragmented ecosystems;
• The effectiveness, verifiability, and confidentiality of computing.

Acurast is a decentralized computing network dedicated to addressing all of the above issues, echoing the call to establish a global cloud computing platform and based on the principles of the open-source movement.

++Technical Architecture Analysis++

1. ++Acurast Orchestrator++ The Acurast Orchestrator is the core component of the consensus layer, responsible for coordinating the scheduling and flow matching of computing resources between processors and developers. The orchestrator plays a key role in defining, reaching, and executing the value exchange between processors and developers.

The built-in flow matching engine of the orchestrator matches publicly available processor resources with the needs defined by developers. The orchestrator natively supports various price discovery mechanisms (such as auctions and advertisements), making the developer experience (DevEx) highly convenient and seamless.

Each agreement between processors and developers exists in the form of a "deployment" entity. A deployment specifically includes: (i) a series of instructions executed on the processor, (ii) scheduling parameters, (iii) settlement configurations (i.e., subsequent processing or storage locations of outputs), and (iv) final reward distribution.

The reward mechanism of the orchestrator is central to the Acurast protocol and consists of two parts:

• Computing/Data Flow
• Reward Flow

Computing/Data Flow For example, data can be observations of public data points (such as from public APIs), off-chain computations, privacy-preserving queries on proprietary data (i.e., permissioned data), or even combinations of the above scenarios.
From the perspective of developer experience (DevEx), this process is similar to defining computing needs with public cloud service providers like Amazon Web Services, Google Cloud, or Microsoft Azure.

Reward Flow In terms of reward flow, developers need to set a budget for the execution of the specified deployment. This budget can be defined using the native token ACU or paid with stablecoins pegged to fiat currency.
This mechanism allows both processors and developers to engage in deterministic financial planning. Once a deployment is successfully executed, the processor will automatically receive the corresponding rewards.

2. ++Architecture Analysis++

Acurast separates the consensus layer, execution layer, and application layer (see Figure 1). Its cloud architecture fundamentally changes the way applications are designed and deployed. The modular architecture provides native settlement capabilities and universal interoperability for the ecosystem, supporting seamless connections between Web3 → Web3 and Web3 → Web2.

Ultimately, Acurast aims to become a decentralized application platform that ensures data privacy and verifiability without introducing any new trust entities.

• Consensus Layer The consensus layer is Acurast's permissionless infrastructure. At this layer, the orchestrator matches developers' deployments with processors, as described in the "End-to-End Process" (see End-to-End Deployment Execution).
  The second core part of the consensus layer is the "reputation engine," which ensures that the reputation scores of processors are correctly updated and incentivizes them to maintain honest behavior.
• Execution Layer The execution layer consists of two important components.
  The first part includes various processor runtime environments, including Acurast Secure Hardware Runtime (ASHR) and Acurast Zero-Knowledge Runtime (AZKR).
  The second part is the Acurast Universal Interoperability Layer, which contains multiple modules for native interactions with different ecosystems.
• Application Layer The third layer is the application layer, where both Web2 and Web3 applications run (see Sec.~\ref{sec:application_layer}).
  Although many DeFi protocols already utilize Acurast, Acurast will continue to drive the development of new use cases that were previously difficult to achieve in a confidential and decentralized manner.

1. End-to-End Deployment Execution

Acurast introduces a paradigm shift in verifiable and confidential computing, driving innovation in the development and deployment of decentralized applications. To demonstrate the internal workings of Acurast, the following describes the entire process of a deployment from definition, publication to completion.

(1) Deployment Registration In the first step, developers need to define the details of the deployment. For example, where should the deployment results be settled, i.e., on which protocol should the deployment output be stored (such as Bitcoin Mainnet). Developers can then choose "ready-to-use deployment templates," which can be adjusted or modified according to needs, or define custom deployments.

Depending on the level of integration between the target ecosystem and Acurast, developers can choose to prepay gas fees and rewards using their preferred native currency (such as Tezos' native token TEZ or Ethereum's ETH) or Acurast's native token ACU.

Next, developers need to specify which processors the deployment should execute on, with options including: (a) private processors, (b) selected known processors (e.g., trusted institutions), or (c) public processors.

• For (a) private processors, no rewards are needed, as this is a permissioned setting;
• For (b) optional rewards;
• For (c), the flow matching engine and Acurast orchestrator will match processor resources with developer deployments.

Additionally, more detailed information about the deployment needs to be declared, such as scheduling parameters (including start time, end time, execution interval, duration of each execution in milliseconds, and maximum launch delay in milliseconds, etc.). Specific resource management parameters, such as memory usage, network requests, and storage requirements, must also be specified.
Finally, the amount of rewards for deployment execution and the minimum reputation requirements (only applicable to (c) public processors) must be declared.
Afterward, the deployment will be recorded on Acurast's consensus layer and enter the OPEN state (see Figure 2).

(2) Deployment Acknowledgment In the second step, processors confirm the deployment and retrieve deployment details from the Acurast chain. Based on the fulfillment definition of the deployment, the deployment Merkle root with assigned proof will be stored on the target chain (e.g., another target chain). At this point, the deployment enters the MATCHED state, and other processors will no longer attempt to confirm the deployment.

The prerequisite for assigning the deployment to a processor is that the processor must be able to fully execute the deployment, adhering to the "all-or-nothing" principle. Since deployments may have different scheduling configurations (e.g., on-demand execution, execution every minute, etc.), the deployment will only enter the ASSIGNED state when the processor confirms it can complete all execution cycles.

(3) Deployment Execution Next, the deployment_script will be executed in the processor's runtime environment. In the example shown in Figure 1, the execution occurs in the Acurast Secure Hardware Runtime (ASHR), meaning that confidentiality of computation is ensured through secure hardware (such as Google's Titan M2 chip). Other runtime environments (such as Acurast Zero-Knowledge Runtime AZKR) can also provide additional reliability guarantees.

(4) Deployment Fulfillment After the deployment execution is complete, the output results will be sent to the pre-declared destination, which may be another Web3 system (such as Tezos, Ethereum) or a Web2 system (such as REST API, federated learning model FL model) for receiving results. If cross-chain transactions are involved, the processor will pay gas fees on the target chain—because developers have locked in the corresponding rewards and gas fees in advance when registering the deployment.

(5) Deployment Reporting After execution is complete, the processor must report the results to Acurast's consensus layer, especially to the reputation engine. If the fulfillment is successful, the report will include the hash of the fulfillment transaction on the target chain; if it fails, the report will contain error information. Ultimately, the deployment will enter the DONE state.

To ensure the reliability of the Acurast protocol, the reputation engine continuously gathers reliability metrics, such as recording and updating after each deployment is completed or fails.

1. Application Layer

In today's internet, almost all applications heavily rely on auxiliary systems. Whether for identity verification via external APIs, infrastructure (such as hosting services), data availability, or reliability, these dependencies can benefit confidential computing applications through extensions or alternative services with core components, effectively eliminating a large number of potential threat events. Given the high centralization of today's internet in logical structure and trust roots (trust anchor), the possibilities brought by Acurast are virtually limitless.

1. Execution Layer

The execution layer of Acurast is modular, allowing for flexible selection of different runtimes based on specific use cases and deployment needs. Decoupling the execution layer from the consensus and application layers allows the runtime to evolve over time, avoiding lock-in to specific technologies. At the same time, this structure ensures that services and confidentiality meet the highest standards, as the security model can continuously upgrade with the emergence of new threats or new demands.

Acurast supports the rapid launch of native, streamlined permissioned alliance networks. Depending on needs, developers can choose (a) to directly select processors from the public processor pool via Acurast Orchestrator, or (b) to use dedicated processors (e.g., processors from trusted entities or self-service processors supported by developers). This combination capability allows developers to customize access control and personalized trust models based on different deployment tasks.

Acurast's execution layer natively supports two runtime environments:
(1) Acurast Secure Hardware Runtime (ASHR) (2) Acurast Zero-Knowledge Runtime (AZKR)

• Acurast Secure Hardware Runtime (ASHR)

Acurast Secure Hardware Runtime (ASHR) is a general approach designed to achieve a confidential execution layer under the assumption of timely threat models, ensuring the highest possible level of security. The security guarantees provided by secure hardware vary greatly, from virtual processors, system-on-chip (SoC) processors, to cutting-edge standalone co-processors, which are physically isolated and dedicated to secure operations [1]. Currently, ASHR is implemented based on Google's Titan chip [2]. Unlike most secure hardware platforms, the Titan chip has not been compromised to date. Although high bug bounties [3] and top 0-day vulnerability rewards [4] do not equate to absolute security, they are important indicators of the security level of the platform.

• Reasons for Using Smartphone Hardware

Smartphones represent one of the most complex scenarios in information security. Their computing power is nearly equivalent to that of computers, storing the most private personal data and executing various security-sensitive operations, making them highly attractive targets for attackers. Due to the wide range of threat models, combined with the vast computational foundation of modern operating systems that are difficult to fully trust, hardware-level security is being adopted by mainstream manufacturers to enhance system security [1].

• About TEE and Hardware Security

Typically, Trusted Execution Environments (TEE) are achieved through direct integration within processors or using external secure elements. However, both approaches cover a narrow threat model, with very limited security guarantees. For example, enclaves integrated into application processors have weak isolation, making them difficult to defend against side-channel attacks. Regardless of the approach, most TEEs cannot establish truly secure communication with peripheral devices, and the operating systems running in these environments lack modern security policies, making them susceptible to various attacks. It can be said that TEEs like Intel SGX [5,6] or ARM TrustZone [7] integrated into main application processors have serious security flaws, especially when facing side-channel attacks. Therefore, ASHR opts for a cutting-edge standalone co-processor architecture.

• Acurast Zero-Knowledge Runtime (AZKR)

Acurast's zero-knowledge proof (ZKP) runtime (AZKR) is another method for achieving general verifiable computing, generating and aggregating proofs for arbitrary computations through recursive zero-knowledge proofs. Although ASHR outperforms AZKR in terms of performance, the trust model of ZKP protocols originates from cryptographic algorithms themselves, rather than relying on hardware security assumptions.

ASHR can horizontally scale across multiple applications, while AZKR requires dedicated circuits and specific assumptions. On the other hand, ASHR provides an isolated environment specifically for sensitive code and is optimized for efficiency. In terms of trust foundations, ASHR tends to rely on key authentication mechanisms and hardware trust models, while AZKR systems primarily depend on semi-trusted sorters and trust in the correctness of cryptographic algorithms.

1. Consensus Layer

The foundation of the Acurast protocol is a permissionless consensus layer that employs an improved Nominated Proof-of-Stake (NPoS) algorithm. Unlike traditional Proof-of-Stake (PoS) networks, NPoS introduces the role of nominators in addition to block validators. The responsibilities of block validators remain to validate transactions and package them into the next block, similar to traditional PoS validators. However, the key difference is that validator nodes are not randomly selected but are nominated by other nodes.

In Acurast's NPoS system, token holders can participate as nominators without limit and support a limited number of validators through staking. A limited number of validators ensures the scalability of the consensus mechanism in the long term and can gradually increase the validator cap through governance decisions. Meanwhile, an unlimited number of nominators allows for a higher overall staking value in the system, enhancing the security of the entire network. Since Acurast's runtime is upgradeable, relevant consensus parameters (such as the maximum number of validators, minimum staking amount for validators, etc.) can also be flexibly configured through governance.

Acurast's NPoS system heavily relies on nominators to ensure the integrity of the network. There are multiple incentive mechanisms between nominators and validators:

• Economic Incentives: Nominators have actual financial stakes in the system, and if the validators they nominate act maliciously, nominators will face financial losses.
• Reward Mechanism: Nominators who select reliable, high-performing validators will receive corresponding economic rewards.
• Reputation Risks: The credibility of nominators is directly related to the performance of the validators they support.
• Competitive Environment: Due to the limited number of validator slots, nominators must make optimal choices among numerous candidates, which not only improves validator quality but also democratizes the governance process, enhancing the importance of voting rights.

NPoS has been proven to be an effective mechanism for achieving high security, scalability, and decentralization in the long term. Consistent with the literature [1], nominators share rewards or bear penalties (such as punitive reductions) in proportion to the amount of ACU they have staked with the nominated validators.

++Summary++

As the first decentralized verifiable computing network driven by smartphones, Acurast has significant advantages: it achieves separation of execution layer, consensus layer, and application layer through a modular architecture, supporting high privacy, high security, and high scalability in task execution. Relying on Trusted Execution Environments (TEE) and dedicated security chips (such as Google Titan M2), Acurast Secure Hardware Runtime (ASHR) provides strong hardware-level privacy protection; meanwhile, Acurast Zero-Knowledge Runtime (AZKR) achieves pure cryptographic security guarantees through zero-knowledge proofs. Its improved NPoS consensus mechanism balances decentralization, security, and governance flexibility, supporting developers in customizing trust models and execution strategies.

However, Acurast still faces some challenges, such as potential performance fluctuations, offline risks, and energy consumption limitations of mobile devices as computing nodes; the high computational complexity of zero-knowledge proofs poses significant barriers for specific applications; additionally, the ecosystem is still in its early stages, and the breadth and stability of applications need continuous validation and expansion. Overall, Acurast has strong potential in the field of trusted computing and decentralized cloud services, particularly suitable for Web3 and Web2 hybrid application scenarios with high privacy and auditability requirements.

# III. Industry Data Analysis

1. Overall Market Performance

As of November 1 (Eastern Time), the total net outflow of Ethereum spot ETFs was $10.9256 million.

1.2. Price Trends of Spot BTC vs ETH

BTC

Analysis

Support levels to watch this week: $105,000 first line, $104,500 second line, $103,000 third line (if not broken, there is a probability of a V-shaped rebound), $100,400 major bottom.

Resistance levels to watch this week: $107,000 (if broken, there is a probability of continuing to rise to previous highs).

ETH

Analysis

Support levels to watch this week: $2,400 first line support (if not broken, there is a high probability of a double bottom rebound trend), $2,300 major bottom (lower boundary of a large range, stabilizing here is an excellent bullish starting point).

Resistance levels to watch this week: $2,550 first line resistance (if not broken, there is a high probability of continuing to explore the bottom), $2,730~$2,790 (upper boundary of a large range, strong resistance, if not broken, continue to oscillate in the range; if broken, there is a high probability of testing the $3,000 mark).

2. Public Chain Data

2.1. BTC Layer 2 Summary

Analysis

1. Ark Protocol Debuts

The Ark protocol proposed by Turkish developer Burak aims to enhance Bitcoin's scalability through virtual unspent transaction outputs (vUTXO) and offline transaction batching mechanisms. Unlike the Lightning Network, Ark does not require pre-allocated liquidity, allowing users to exit the system at any time, ensuring fund security. Currently, Ark Labs and Second are developing the implementation version of this protocol.

2. Botanix Network Node Expansion

Botanix Labs announced that 16 institutions, including Galaxy, Fireblocks, Alchemy, Antpool, and UTXO Management, have become node operators for its Bitcoin Layer 2 network. This network uses the Spiderchain protocol, compatible with the Ethereum Virtual Machine (EVM), supporting DeFi applications such as BTC-collateralized stablecoin Palladium, decentralized exchange Bitzy, and lending market Spindle.

3. Bitcoin Solaris Project Pre-sale

Bitcoin Solaris (BTC-S) announced that its sixth phase of pre-sale is entering its final day, priced at $6 per token, with an expected public offering price of $20. This project employs a dual consensus mechanism: the base layer uses SHA-256 compatible with Bitcoin, while the Solaris layer uses DPoS, supporting up to 100,000 transactions per second (TPS). Currently, over 11,000 investors have participated, raising over $3 million.

4. Bitcoin Hyper Project ICO Fundraising

Bitcoin Hyper is a Bitcoin Layer 2 solution based on the Solana Virtual Machine (Solana VM), aimed at addressing the slow transaction speeds and high fees of Bitcoin. The project has raised over $500,000 through its initial coin offering (ICO), with a token price of $0.011775. Users can participate in staking, trading, and governance through its native token $HYPER.

2.2. EVM & Non-EVM Layer 1 Summary

Analysis

1. Skate Multi-VM Infrastructure

• Cross-Chain Support: Skate is a multi-virtual machine infrastructure that allows any decentralized application (dApp) to run on both EVM and non-EVM blockchains.
• Unified Liquidity: Its core automated market maker (AMM) promises to provide a unified liquidity curve across all chains.

2. BlockDAG Project

• Pre-sale Performance: BlockDAG raised over $287 million in its pre-sale in June 2025, attracting significant attention.
• EVM Compatibility: The project supports full EVM compatibility, allowing Ethereum applications to migrate easily.

2.3. EVM Layer 2 Summary

Analysis

1. Plume Network Mainnet Launch, Promoting Tokenization of Real World Assets (RWA)

Plume Network launched its mainnet on June 5, successfully tokenizing assets worth $150 million and reaching an agreement with Mercado Bitcoin to tokenize $40 million of assets in Brazil. The platform processed 280 million transactions during the testnet period, indicating strong demand for RWA tokenization.

2. Litecoin Launches EVM-Compatible Layer 2 Network LitVM

Litecoin launched LitVM on June 2 at the Litecoin Summit, the first EVM-compatible Layer 2 network based on Litecoin. This network employs zero-knowledge proof (ZK) technology, supports cross-chain exchanges, and is compatible with Bitcoin and Cardano, aiming to enhance Litecoin's role in decentralized finance (DeFi).

3. Security Enhancements for Base Network

The security of the Base network has been strengthened, further solidifying its position as an Ethereum Layer 2 solution. The enhancements improve its support for decentralized applications.

4. Technical Progress: UAT20 Standard Proposal

Researchers have proposed the UAT20 standard to address liquidity fragmentation across Rollups. This standard achieves liquidity unification across Rollups using Conflict-free Replicated Data Types (CRDTs) and a two-phase commit protocol.

# IV. Macroeconomic Data Review and Key Data Release Nodes for Next Week

In May, the U.S. unemployment rate remained steady at 4.2%, unchanged from April, in line with market expectations, and has fluctuated within a narrow range of 4.0%-4.2% since May 2024, indicating overall stability in the labor market and proximity to full employment levels.

In May, the seasonally adjusted non-farm payroll increased by 139,000, exceeding the market expectation of 125,000 but slightly lower than the revised increase of 147,000 in April. Employment data for March and April were both revised downward, with a cumulative decrease of about 95,000, indicating a slowdown in job growth during the spring.

Important macroeconomic data nodes for this week (June 9 - June 13) include:

June 11: U.S. unadjusted CPI year-on-year for May

June 12: Initial jobless claims for the week ending June 7 in the U.S.

# V. Regulatory Policies

U.S.: Accelerating Construction of Regulatory Framework

• CLARITY Act Progress: The U.S. Congress is advancing the CLARITY Act, aimed at clarifying the roles of the Securities and Exchange Commission (SEC) and the Commodity Futures Trading Commission (CFTC) in cryptocurrency regulation. The bill has bipartisan support and is expected to undergo further review on June 10.
• SEC Clarifies Staking Guidelines: The U.S. Securities and Exchange Commission (SEC) issued a statement clarifying that staking activities do not constitute securities issuance, alleviating compliance pressure on the cryptocurrency industry.
• Stablecoin Regulatory Progress: The U.S. Senate passed the GENIUS Act, requiring stablecoin issuers to maintain 100% reserves in U.S. dollars or short-term government bonds and provide regular updates to consumers.
• Circle Successfully Goes Public: U.S. stablecoin issuer Circle successfully went public on the New York Stock Exchange, raising $1.05 billion, with stock prices rising by 168%, reflecting institutional confidence in the cryptocurrency market.

U.K.: Gradual Relaxation of Regulatory Policies

• FCA Considers Lifting Ban on Retail Investors for Crypto ETNs: The U.K. Financial Conduct Authority (FCA) plans to lift the ban on retail investors purchasing cryptocurrency exchange-traded notes (ETNs), aiming to support the growth and competitiveness of the U.K. crypto industry.
• MiCA Regulatory Technical Standards Supplement: The European Commission passed supplementary regulatory technical standards for the Markets in Crypto-Assets (MiCA) regulation on June 5, further standardizing the regulatory framework for crypto assets.

India: Upcoming Release of Crypto Policy Discussion Document

The Indian government plans to release a discussion document on cryptocurrency policy in June, aiming to provide a legal framework for the crypto industry and address tax and regulatory issues.

Czech Republic: Bitcoin Donation Scandal Triggers Political Storm

The Czech Minister of Justice resigned after accepting a donation of 468 bitcoins from a convicted criminal, sparking a political scandal and raising concerns about cryptocurrency regulation.

Argentina: $LIBRA Cryptocurrency Scandal

The $LIBRA cryptocurrency project promoted by Argentine President Javier Milei faced scandal due to a price crash, resulting in $25 billion in losses for investors and raising questions about government regulatory responsibilities.