I. Outlook

1. Macroeconomic Summary and Future Predictions

Last week, the U.S. stock market continued its strong performance, with the S&P 500 and Nasdaq indices reaching new historical highs, supported by the technology and AI chip industries. There are diverging expectations regarding Federal Reserve policy, with some members calling for a 25 basis point rate cut in July, but frequent interventions by the Trump administration have raised concerns about the stability of monetary policy. The direction of the economy and the market in the coming months will heavily depend on the development of trade situations, inflation trends, and the actual path of Federal Reserve monetary policy adjustments.

2. Market Changes and Warnings in the Crypto Industry

Starting from July 14, the U.S. House of Representatives is holding a "Cryptocurrency Week," focusing on reviewing multiple policy frameworks. Such policy movements have significantly boosted Bitcoin prices and expectations for the legalization of the crypto market. Continuous institutional inflows and favorable legislation create a positive foundation, but high leverage and overbought conditions increase short-term volatility risks. It is recommended that investors maintain a structurally bullish outlook while enhancing risk management awareness, closely monitoring the progress of subsequent bills and market funding dynamics, especially paying attention to risk signals in the derivatives market. Overall, the crypto industry is entering a new era of regulation and large-scale institutional participation, with future volatility expected to remain high.

3. Industry and Sector Hotspots

Raising $18 million, Veda — a native yield infrastructure project backed by BitGo and Coinbase, simplifies cross-chain DeFi operations and yield embedding; raising $10 million, Units.Network — a modular Layer-0 chain factory supporting inter-chain interoperability.

II. Market Hotspot Sectors and Potential Projects of the Week

1. Overview of Potential Projects

1.1. Analysis of Veda — a native yield infrastructure project raising $18 million, simplifying cross-chain DeFi operations and yield embedding

Introduction

Veda is a DeFi vault infrastructure (vault primitive), which is a protocol-level mechanism for asset pricing, accounting, security, optimization, and automated management. It features non-custodial, trust-minimized, and composable characteristics, enabling enterprises, asset issuers, protocols, blockchains, public chain wallets, and applications to develop enterprise-grade DeFi products without the need to rebuild complex smart contracts and off-chain infrastructure.

By abstracting complex processes such as cross-chain operations, yield optimization, and risk mitigation, Veda significantly lowers the barriers for consumers and institutions to participate in on-chain finance. Protocols integrated with Veda can provide users with real-time and transparent security guarantees, achieving seamless access.

Veda has consistently maintained a market-leading position in the vault and asset curation space, with major achievements including:

• Recognized as the largest vault provider and asset curator in DeFi, managing a total locked value (TVL) exceeding $3 billion, with over 100,000 users;
• Developed BoringVault, the most widely used vault standard in DeFi;
• Facilitated the launch of the first vault token eBTC on the Aave main market;
• Integrated into Binance Web3 wallet and ByBit Web3 wallet.

Architecture Overview

Veda's Methodology: Cross-chain Composable DeFi Vault Infrastructure (Vault Primitive)

The DeFi vault infrastructure allows developers to more easily attract capital, reduce risks, and optimize ecosystem liquidity. Veda's BoringVault is at the core of this process, achieving the following functionalities:

• Standardized pricing and accounting: Real-time tracking of user balances and vault share valuations;
• Adaptive configuration: Dynamic allocation of capital to different yield strategies;
• Automated optimization: Continuous adjustments to achieve the best risk-return ratio;
• Rapid iteration: New vaults or updated strategies can be deployed in as little as 48 hours.

Core Differentiating Features:

• Protocol, asset, and chain independence: Seamlessly operates across multiple blockchains (including EVM, SVM, MoveVM, etc.) and integrates with various DeFi protocols;
• Support for any complex strategy: Combining off-chain logic with a modular architecture, vault curators can run multiple on-chain yield strategies within the same vault;
• Verifiable constraints: Vault operations are limited to a whitelist of on-chain visible actions;
• Non-custodial mechanism: User funds are stored in audited smart contracts without the need for centralized custody;
• Strong composability: Can flexibly combine with lending markets, decentralized exchanges (DEX), and yield trading protocols to build powerful financial applications. For example, Veda vault shares are the first vault tokens accepted as collateral in the Aave main market.

BoringVault Architecture and Fund Flow: Modular Design of Enterprise-grade DeFi Security Framework

BoringVault is built from the ground up to become the safest and most flexible enterprise-grade DeFi product development framework.

Its modular architecture employs minimal core contract logic (about 100 lines of code, hence referred to as "boring" vault), with core functionalities relying on multiple utility smart contract modules:

• BoringVault (the vault itself)
  The main deposit contract for user assets. The internal logic is extremely simple, enhancing flexibility and security by delegating tasks to external modules.
• Teller (cashier module)
  Responsible for handling user share minting and redemption operations, managing deposits, enforcing share lock-up periods, and can refund under specific conditions to protect user rights.
• Hook (optional hook module)
  A module that triggers custom logic before share transfers, which can be used to restrict transfers or perform additional security checks. Typical use cases include contract-level compliance functions, such as whitelisting deposit addresses and locking shares.
• Manager (asset management module)
  Responsible for rebalancing vault assets. Through the Merkle proof mechanism, it ensures that only authorized and predefined strategies are executed, thus strictly controlling vault behavior.
• Accountant (accounting module)
  Calculates and updates the exchange rate of vault shares. Ensures that exchange rate changes remain within acceptable ranges, and can pause updates in case of abnormal fluctuations to prevent losses from extreme market conditions.
• uManagers (micro-managers)
  Introduces additional logic during rebalancing. For example: enforcing configuration limits, slippage check validation, or fully on-chain automated strategy execution.
• DecoderAndSanitizer (decoder and security filter)
  Decodes and sanitizes data when integrating new external protocols, ensuring that only safe and expected operations are executed.
• Oracle (oracle module)
  Used to track yield and underlying asset values, following on-chain verification mechanisms, such as maximum update frequency and maximum price deviation, to ensure information is authentic and reliable.

Fund Flow Process

1. Users initiate deposits through Teller, which calls the transfer Hook and issues vault share tokens to users based on the exchange rate provided by Accountant.
2. Funds will remain in the vault contract until allocated (approximately every 24 hours).
3. Curator allocates funds to selected DeFi protocols through a Merkle tree whitelist mechanism.
4. When users need to withdraw, they send their vault shares to the withdrawal contract in exchange for the corresponding underlying assets (which may require waiting for an optional unlock period). Note: Separating withdrawal logic from core vault logic has security advantages.
5. Every 24 hours, the Oracle updates the vault exchange rate through the Accountant, reflecting the interest or yield generated.

Commentary

As a native DeFi yield infrastructure, Veda possesses significant advantages such as modularity, non-custodial, and composability, supporting cross-chain operations, complex strategy execution, and enterprise-grade product construction, significantly lowering development barriers and enhancing security and flexibility. Its representative vault, BoringVault, achieves efficient asset management and dynamic yield distribution through minimal core logic and pluggable module design.

However, its strategy execution and cross-chain dependencies on many external modules and oracles may pose certain operational risks and synchronization challenges under extreme market conditions or inter-chain communication delays.

1.2. Interpretation of Units.Network — a modular Layer-0 chain factory raising $10 million, supporting inter-chain interoperability

Introduction

Unit Zero is a high-performance, scalable, and secure network based on Waves, compatible with EVM, featuring decentralized governance and future-oriented interoperability, utilizing the LPoS consensus mechanism and driven by the Unit 0 incentive mechanism.

Architecture Overview

Unit Zero is a high-performance network built on the Waves blockchain, with the following advantages:

• Provides excellent scalability, security, and decentralization features
• Features an innovative architecture that enables multi-chain interconnectivity within the ecosystem

Core Functions:

• EVM compatibility: Supports rapid deployment of dApps to the Unit Zero network
• High performance and scalability: Utilizes LPoS consensus for efficient transaction processing
• Decentralized governance: Community-driven network management and decision-making mechanisms
• Unit0 incentive mechanism: Rewards for block production, governance participation, and ecosystem development projects
• Inter-chain interoperability: Future-oriented, supporting integration with other blockchains

Workflow Breakdown
The Unit Zero network consists of a series of interconnected nodes.

Note: The Layer-1 network of Unit Zero also utilizes some Waves Layer-0 nodes.

Chain contracts maintain consensus in the Layer-1 network through the following means:

• Generator commitment: Generators commit to participating in the production of Layer-1 blocks.
• Epoch management: Each Layer-0 block corresponds to a Layer-1 epoch.

Fair PoS algorithm, mechanism as follows:

• Calculate the delay in generating Layer-1 blocks.
• Define the qualifications for block creation.

Block Creation: Selected Generators:

• Package transactions into Layer-1 blocks.
• Sign the blocks.
• Record block metadata on Layer-0.

Fork Resolution: Prioritize the generator chain that controls over 50% of the Layer-1 generation balance.

Core Element Breakdown

1. Nodes

Nodes are the fundamental components that maintain the integrity of the blockchain, functioning by storing data, validating transactions, and ensuring consensus and data accuracy.

Unit Zero nodes consist of two components:

1. Execution Client: Handles transactions and updates the blockchain state. The execution client communicates with each other within a peer-to-peer network and processes JSON-RPC API requests.
   Note: Hyperledger Besu can serve as an execution client.
2. Consensus Client: Responsible for adding blocks and achieving consensus among network participants.
   Note: Waves nodes with the ConsensusClient extension act as consensus clients.

Rewards
By running a node, you can earn rewards in the following ways:

1. Transaction Fees: Fees from processed transactions.
   Note: Fees vary based on network traffic and transaction volume. You can view an example block to see the amounts received in the "Transaction Fees" column.

2. Block Rewards: Rewards obtained by participating in cross-network block creation.
   Note: The Unit Zero network employs the WAVES LPoS consensus mechanism, ensuring equal probability of block generation.

3. Network Architecture

The Unit Zero network consists of interconnected node chains, including Layer-0 and Layer-1 network structures. The collaboration between these layers ensures efficient blockchain operations while maintaining network stability and security.

• Layer-0 provides an underlying infrastructure to ensure cross-chain interactions and the execution of consensus protocols.
• Layer-1 is responsible for specific transaction validation and block generation, collaborating with the Layer-0 network.

1. Consensus Mechanism

Unit Zero uses the WAVES LPoS (Leased Proof of Stake) consensus mechanism, participating in the production of Layer-1 blocks through generator commitments. Its core features include:

• Fair block generation: Generators have equal opportunities to participate in block creation.
• Fork resolution: Prioritize the generator chain that controls over 50% of the generation balance.

1. Network Environment

The Unit Zero network operates in two different environments:

• Mainnet: Handles transactions and user operations involving real assets, with actual economic value.
• Testnet: Provides a secure environment for developers and users to conduct risk-free functional testing and optimization.

Through these components, Unit Zero achieves an efficient, secure, and decentralized blockchain ecosystem that supports complex transaction operations and scalability testing.

Commentary

The advantage of Unit Zero lies in its multi-layered architectural design, combining Layer-0 and Layer-1 networks to provide efficient scalability and stability. It employs the WAVES LPoS consensus mechanism to ensure fairness in block generation while achieving strong consensus guarantees through chain contracts. Additionally, the node structure is flexible, supporting developers in risk-free development and debugging between the mainnet and testnet.

The disadvantage is that reliance on multiple layers of networks and consensus mechanisms may lead to higher initial technical complexity and stricter management requirements for nodes. While the reward mechanism encourages user participation, the actual size of rewards may be affected by fluctuations in network traffic and transaction volume.

2. Detailed Explanation of Key Projects of the Week

2.1. Detailed Explanation of the $135 Million Financing, Canton Network — An Institutional-Level Layer-1 Blockchain Network Governed by Financial Institutions, Supporting Atomic Transactions and Privacy Protection

Introduction

Canton Network is a public Layer-1 blockchain launched by Digital Asset, specifically designed for institutional financial scenarios, featuring privacy, interoperability, and scalability. Built on DAML smart contracts, it implements an "on-demand visibility" privacy mechanism, allowing different participants to access only the transaction data relevant to them. The network is supported by the Global Synchronizer Foundation under the Linux Foundation and is jointly governed by multiple financial institutions, supporting atomic-level cross-application transactions such as tokenized bonds and cash while ensuring account isolation and compliance controls.

Similar to existing blockchain networks, Canton Network achieves real-time synchronization of sensitive data among participants. It possesses private chain-level privacy protection capabilities on a public chain network, with various applications sharing a common ledger view. Canton Network utilizes the powerful smart contract language Daml, which can embed programmable privacy mechanisms for each asset or data fragment. The Canton protocol also allows each application to scale independently, enhancing usability while maintaining low costs.

Feature Analysis

1. Daml

Daml is an open-source smart contract language and development framework designed to simplify the development, execution, and maintenance of multi-party applications while ensuring privacy protection and data consistency. More specifically:

• Daml provides concepts for describing real-world business transaction rules, helping programmers focus on business logic and avoid common security vulnerabilities.
• Daml allows defining access and authorization policies within smart contract code, facilitating synchronized management. Data is confidential by default, and access policies are easy to define, enabling smart contract developers to understand and maintain them easily.
• Daml supports application interoperability, allowing workflows to be combined into more complex processes, even if these workflows are deployed across different applications on different networks. Any participant can unilaterally extend functionality by combining existing workflows, promoting natural growth of the ledger and helping manage complexity. Daml achieves workflow composition across application networks while ensuring confidentiality and authorization requirements for each application.
• Daml supports interoperability with other systems through integrated tools, including automatically generating bindings for common programming languages, bridging tools for connecting to other blockchains, and providing general standards and domain-specific libraries.

Contracts
Daml defines a "contract" as a codified agreement reached by multiple participants in the network regarding a specific workflow; these participants are referred to as contract signatories. Additionally, there are participants who can only view the contract but do not sign it, known as contract observers. A participant can be an individual entity signing with a private key or a consortium organization using flexible multi-signature strategies. Therefore, assets can be issued by centralized entities or co-signed by a consortium of multiple institutions.

Transactions
Contracts are created in a transaction and are considered "effective" once created. Subsequent transactions may archive (archive) the contract, rendering it "inactive."

To ensure consistency among participants in the network while protecting privacy, transactions must possess two key characteristics:

1. There must be a mechanism to ensure that different participants reach consensus on the transaction order to prevent view discrepancies;
2. Different participants can only access the portions of the transaction relevant to them based on the privacy definitions of their contracts, a mechanism known as "sub-transaction privacy." Each participant can only see and verify the transaction fragments relevant to themselves, referred to as "sub-transactions."

All active contracts in the system are referred to as the "Active Contract Set" (ACS), and their status is generated by the transaction graph. Each transaction can create or archive contracts while referencing the contracts it depends on. New transactions are atomic changes added to the end of the transaction graph and may contain multiple sub-transactions, with different participants seeing different sub-transaction content, thus each participant's observed ACS is a subset of the global ACS.

This transaction model is similar to the UTXO model used by public chains like Bitcoin, but with two significant differences:

1. No participant can see the complete transaction graph; each participant can only see their own visible subgraph (view), unlike Bitcoin or Cardano, where everyone on-chain can view the entire network's transaction graph;
2. Transactions do not necessarily archive the contracts they reference (i.e., UTXO). Whether to archive depends on application logic and can be defined using the consuming and non-consuming keywords in Daml. In contrast, in Bitcoin, once a UTXO is referenced, the system must consider it used (archived).

Additionally, the transaction structure in Daml is tree-like, supporting workflow composition. The tree structure of existing workflows can be integrated as subtrees within more complex workflows. Each participant only needs to verify the subtrees relevant to themselves, while other parts can be ignored.

Figure 1: Example of a transaction graph with sub-transaction privacy. Alice and Bob can only see a portion of the complete transaction graph. Initially, there are three active contracts, and each participant can only see two of them. Transactions 1 and 2 are submitted by Alice and Bob, respectively, updating the Active Contract Set (ACS): archiving two initial contracts, creating two new contracts, and creating and archiving two temporary contracts. After these two transactions, there are three active contracts in the system (shown in purple), and each participant can only access two of them.

In other words, the ledger model of Canton differs from other blockchains primarily in that, in Canton, each participant can only see a portion of the Active Contract Set (ACS) and a subgraph of the global transaction graph, referred to as that participant's "view." This participant-specific view itself is a legitimate ledger and can be locally verified by that participant's node, without needing to trust any other participants throughout the process.

When a transaction or sub-transaction reaches a participant's node, that node will perform three verifications:

1. Is the transaction consistent with the current view?
2. Does the transaction comply with the logic written in the smart contract?
3. Has the transaction received the correct authorization?

Smart Contract Language

Daml is a modern functional programming language with a static type system that can exclude various unexpected behaviors and logical errors at the compilation stage.

Developers define data structures, workflow semantics, and transaction execution logic through "contract templates." Templates are conceptually equivalent to class definitions in object-oriented programming or data table structures in databases. Each template includes the following:

• Arguments: The data stored in the contract.

• Choices: Actions that participants can perform on the contract. Equivalent to methods in object-oriented programming or stored procedures in databases.

• Authorization:

• Signatories: Must authorize the creation or archiving of the contract;

• Observers: Other parties that can view the contract but do not participate in operations;

• Controllers: Participants who can take specific actions on the contract by executing choices.
  A participant can delegate their authority to others to perform specific actions. When a transaction uses a party's authority, that party will be able to see that operation.

• Constraints: Conditions that all instances of the template must satisfy, defined using the ensure keyword.

Ledger Model

The ledger data model of Daml adopts a different approach from traditional blockchains to address privacy and scalability issues. In the Daml model, the ledger is not fully replicated among all participants but is partitioned according to privacy rules, with each participant storing only the "view" or "ledger shard" relevant to themselves. Therefore, there is no single shared ledger copy among all participants; instead, each participant has a ledger that contains only their own contracts. When a transaction occurs, only the relevant parties will update their respective ledger views.

This presents a challenge: how to ensure the accuracy and consistency of contract records when they are dispersed across many ledgers visible only to specific participants? Daml addresses this issue by introducing the concept of a "virtual global ledger." The ledger views of all participants are considered a subset of a global virtual ledger. This virtual ledger does not exist in any specific data storage but is ensured through a consistency mechanism (Canton protocol) that guarantees each properly functioning node's ledger view is a valid subset of this global ledger.

Additionally, Daml's design supports a "network of networks" architecture. Each participant can connect to one or more subnets, and the Canton protocol can synchronize digital asset transactions between these subnets. This architecture not only ensures privacy but also enhances performance and scalability.

Ultimately, Daml's fully decentralized, participant-centric ledger model not only ensures the privacy and correctness of contract and asset ownership but also allows users to freely combine and build distributed finance and business networks across multiple subnets.

Figure 2: The ledger model of Canton. Each participant has their own valid ledger, and the Canton protocol synchronizes the states of all parties by maintaining consistency with the global ledger. The global ledger is virtual, meaning no single participant stores its complete content. In this example, the Active Contract Set (ACS) contains six contracts, but each participant can only access 2 to 4 of them, as indicated in blue in the figure.

2. Canton

Canton is an open-source blockchain protocol with privacy protection capabilities, specifically designed to implement the Daml ledger model. Its core features include:

• Participant Nodes: Nodes representing a user or institution, deployed by that party, which can be multiple, responsible for executing contract operations on behalf of that party in the network.
• Sync Domains: Communication components operated by Canton Service Providers (CSP), responsible for message ordering, encrypted transmission, and timestamp management. Each participant node interacts with other nodes by connecting to one or more sync domains.
• CSP and vCSP: CSP can be a single entity or a "virtual CSP" (vCSP) composed of multiple participants, achieved through the joint deployment of distributed sync domains. Anyone can deploy new sync domains to meet performance, compliance, geographic, and other needs.
• Encrypted Communication and Neutrality: All data transmitted by sync domains is encrypted, and CSP cannot read the message content, thus ensuring privacy and network neutrality.
• Network Topology: Canton builds a "composable mesh network" consisting of Daml applications, where each application can choose its trust model, access control strategy, and operational complexity trade-offs based on its needs.

Figure 3: Canton network topology. Participants are interconnected through Canton Service Providers (CSP) or virtual CSP (vCSP) composed of alliances. As long as a participant's node connects to the same CSP or vCSP, transactions can occur. There is no situation in the network where a single node needs to handle all transactions.

While individual nodes have limitations in processing power and storage, the Canton network itself does not have inherent scalability bottlenecks: participating nodes only process data and workflows relevant to themselves, while different sync domains can synchronize this data in parallel. Participants can freely choose to connect to any sync domain, as long as the CSP of that sync domain accepts their connection request. Open sync domains allow any compliant requests to join.

Canton supports a public permissioned network, where anyone can deploy Canton sync domains for various reasons and become a CSP. Sync domains are not isolated; participants sharing one or more sync domains can combine to create more advanced workflows, including multi-application atomic transactions processed through the chosen sync domains. Contract signatories and observers can control which sync domains are responsible for synchronizing their contracts and can choose to reassign the sync domains responsible for contract ordering, thus avoiding lock-in or censorship of sync domains.

The following diagram illustrates the sequence of events in reassigning the synchronization responsibility of a contract from sync domain 1 to sync domain 2.

Figure 4: Sequence diagram of sync domain reassignment. Contract signatories can mutually agree to transfer the synchronization responsibilities of a contract from one sync domain (and its corresponding CSP) to another sync domain.

Data Pruning and Compliance:

Canton supports the pruning and redaction of historical data, allowing node operators to balance audit capabilities and compliance requirements (such as the "right to be forgotten" under GDPR) by migrating historical data to offline storage to reduce costs and maintain environmental sustainability. By continuously exchanging encrypted commitments, it ensures that even when historical data is pruned, participants can still guard against malicious denial of service.

Stakeholder Consensus Mechanism (Proof-of-Stakeholder):

Canton employs a two-layer consensus protocol to ensure data consistency and privacy.

• The first layer is a two-phase commit protocol that allows contracts to be replicated only among relevant stakeholders and enables each stakeholder to verify transactions, achieving subset state machine replication.
• The second layer is an ordering protocol responsible for determining the timestamps and execution order of transactions, ensuring the determinism of transaction processing. The ordering protocol can be executed by centralized CSPs or run in distributed sync domains of virtual CSPs, secured by Byzantine Fault Tolerance (BFT) algorithms.

Figure 5: Atomic asset exchange transaction. The asset exchange will only succeed if all signatories agree to the two sub-transactions; otherwise, the transaction is rejected, and the assets do not transfer. Alice and Bob can view the complete transaction content, while Issuer 1 and Issuer 2 are only entitled to view parts of the transaction.

Application Composability

In Canton, two or more applications can combine and rely on atomic transactions, even if they synchronize through different sync domains. For example, two central banks can synchronize domestic currency transactions in their respective CSPs, while currency holders can still atomically exchange currencies in cross-sync-domain transactions.

While, like other blockchains, global composition can be achieved through a single global sync domain, having multiple sync domains brings many advantages. For instance, enterprises and individuals can better control their network resources; a single global sync domain may lead to excessive communication delays for some participants; multiple sync domains can process requests in parallel, increasing throughput; critical workflows can use newly restricted access sync domains; and different sync domain operators may have different fee structures. In the above example, domestic currency transactions are processed within the jurisdiction of the central bank.

However, multiple sync domains also pose challenges for cross-domain workflow composition. In Daml, combining workflows means that contracts synchronized by different sync domains can be used together in a single transaction. Without this capability, multiple isolated networks would emerge, preventing the formation of a truly interoperable network.

Canton guarantees the atomicity of cross-subnet transactions. Since different sync domains do not have a common ordering of the sub-transactions they process, balancing atomicity and system robustness becomes complex. To address this, Canton only allows cross-subnet transactions when all transaction participants are connected to at least the same sync domain, and the contract changes involved in the transaction are synchronized through that common sync domain. Additionally, Canton supports changing the sync domain of contracts, switching the ordering authority from one sync domain to another, enhancing flexibility.

Figure 6: Example network topology. Participants connected to multiple sync domains can combine to achieve atomic transactions across subnets, thus supporting the construction of transaction workflows across multiple applications and networks.

Conclusion

Canton, as a privacy-preserving open-source blockchain protocol that supports multiple sync domains, has advantages in its unique virtual global ledger model and sharded storage design, which ensure data privacy and security while enhancing system scalability and performance. At the same time, the flexible sync domain architecture supports cross-domain atomic transactions and network interoperability, adapting to diverse application scenarios and compliance needs. However, its disadvantages may include higher system complexity, stringent coordination requirements for nodes and sync domains, and the need to ensure stable connections and consensus among multiple parties when implementing large-scale cross-domain transactions, presenting certain technical barriers.

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.1. Spot BTC vs ETH Price Trends

BTC

Analysis

Key Resistance: $118,700, $120,700, $122,000

Key Support: $118,100, $117,600, $115,700

ETH

Analysis

Key Resistance: $3,820, $4,020, $4,110

Key Support: $3,680, $3,530, $3,480

2. Public Chain Data

2.1. BTC Layer 2 Summary for the Week

1. Bitcoin Hyper Launch

• The world's first Bitcoin Layer-2 based on Solana VM (SVM).
• Utilizes ZK technology to bridge BTC, achieving high-performance, programmable BTC applications.

1. Lightning Node Revenue Requires Active Management

• Reports indicate that Lightning nodes cannot operate in a "free-range" manner.
• Nodes need to regularly optimize fees and ensure online status to maintain revenue.

1. Explosive Growth of BTC Native DeFi

• BTC ecosystem DeFi TVL surged from $300 million to $6.36 billion.
• Indicates that BTC Layer-2 applications are beginning to expand on a large scale.

1. LayerBTC Release Plan

• Modular BTC Layer-2 project focusing on smart contracts and RWA support.
• Positioned for institutional-level payments, asset issuance, and DeFi networks.

1. Lightning Enterprise-Level Expansion

• Multiple enterprises integrated Lightning payments, reducing costs by 50%.
• Supports stablecoin (e.g., USDT) payments, enhancing commercial viability.

2.2. EVM & Non-EVM Layer 1 Summary for the Week

1. Viction Non-EVM Chain Rapid Rise

Viction achieved significant growth in the second quarter: daily active users increased from 10,000 to 40,000, monthly transaction volume reached 16.2 million, and TVL rose from $2.9 million to $12 million. Its zero Gas architecture and PoSV consensus mechanism effectively promote network participation.

2. Cosmos Stops EVM Expansion, Focuses on Native IBC Architecture

The Cosmos project has officially halted its planned EVM expansion path and fully returned to the IBC (Inter-Blockchain Communication) cross-chain communication protocol. This decision enhances Cosmos's concentrated investment in multi-chain interoperability.

3. Euclid Builds Unified Cross-Chain Liquidity Protocol

Euclid announced the launch of a unified liquidity layer that virtualizes cross-chain asset handling without the need for actual asset migration. Its design is compatible with multiple cross-chain protocols, including IBC, CCTP, and Axelar, and will be driven by its native token $EUCL for the incentive model.

4. Aave DAO Approves Aptos Integration, First Entry into Non-EVM Chain

The Aave community voted to deploy the V3 protocol on Aptos, becoming its first non-EVM public chain integration. This deployment will first land on the Aptos testnet, supporting multiple mainstream stablecoins and Aptos native assets.

5. Injective Launches Native EVM Testnet

Injective has launched a new native EVM test chain, supporting up to 20,000 TPS, compatible with Ethereum, Cosmos, and Solana assets, with extremely low on-chain latency. Its DAU surged from 5,000 to 81,000, and it simultaneously launched an RWA (real asset) tokenization project.

6. The Graph Expands to Multiple Non-EVM Networks

The Graph has completed support for non-EVM networks such as Solana, Stellar, and Near, further enhancing its on-chain data indexing capabilities and launching "Token API" and knowledge graph products to serve AI data needs and DePIN projects.

7. Caldera Becomes Representative of Rapid Rollup Deployment Tools

Caldera successfully launched a one-click elastic deployment EVM Rollup toolchain, significantly simplifying the threshold for developers to deploy custom Layer-2 networks. This toolchain is being integrated by multiple Layer-2 projects.

2.3. EVM Layer 2 Summary for the Week

1. XRP Ledger Launches EVM Sidechain

The EVM-compatible sidechain of XRP Ledger officially went live in early July, deploying approximately 1,412 smart contracts within a week, covering DeFi projects and protocols similar to Uniswap. The network generates a block every 5.66 seconds, with no congestion, and transaction fees are only 0.048 XRP, indicating its potential to attract developers and its low-cost advantage. Although daily active users are still fewer than 150, the ecological development shows a positive trend.

2. Polygon Major Optimization: Bhilai Hardfork and Second-Level Finality

Polygon successfully completed the "Bhilai Hardfork" upgrade on July 1, reducing transaction finality from one minute to about five seconds and enabling features such as account abstraction, paving the way for the next phase of the "Gigagas" 100K TPS expansion plan. This upgrade greatly enhances user experience and payment settlement efficiency.

3. Robinhood Launches Self-Built EVM Layer-2 and Stock Tokenization

Robinhood announced the launch of Tokenized Stock (U.S. stock tokens) trading based on Arbitrum in the EU and plans to build its own EVM-compatible Layer-2 mainnet, expanding services to its self-developed chain, supporting round-the-clock trading, automatic dividends, and user self-custody. This marks a milestone in the penetration of traditional financial platforms into on-chain finance.

4. Caldera: Rapid Deployment of Customized EVM Rollups

Layer-2 Rollup platforms represented by "Caldera" are gaining developer attention, with the ability to "one-click elastic deploy EVM chains," supporting project parties in quickly building custom chains. This platform is seen as an important infrastructure tool in the development of the Layer-2 ecosystem, accelerating the application landing cycle.

5. Little Pepe Meme Coin Ecosystem Active

$LILPEPE is a meme coin deployed on EVM Layer-2, currently still in the presale stage, having raised over $3 million. The project leverages low transaction costs and high processing advantages, targeting areas such as Web3 gaming, DeFi, and original meme scenarios, demonstrating a certain level of community activity and ecological expansion potential.

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

In June, U.S. CPI core inflation showed upward pressure. Core CPI and overall CPI are expected to rise by 0.2% to 0.3% month-on-month, with core inflation rising to 2.9% year-on-year and overall inflation to 2.6%. Annual inflation remains around 2.4%, slightly above the Federal Reserve's target but generally controllable.

Important macroeconomic data nodes for this week (July 21 - July 25) include:

• July 23: U.S. EIA crude oil inventory for the week ending July 18
• July 24: U.S. initial jobless claims for the week ending July 19

V. Regulatory Policies

United States

• GENIUS Act Officially Becomes Federal Law

• The President signed the GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins), establishing a regulatory framework for stablecoins.

• Requires stablecoin issuers to meet 1:1 reserves, disclose reserve reports monthly, and prohibits members of Congress and their immediate family from profiting.

• The bill grants federal-level regulatory legitimacy, clearing obstacles for institutional adoption.

• "Crypto Week" Three Bills Progressing Together

• The House passed three key pieces of cryptocurrency legislation:

• GENIUS Act: Stablecoin regulatory standards.

• Clarity Act: Clarifies CFTC's regulatory authority over crypto assets.

• Anti-CBDC Surveillance State Act: Prohibits the U.S. government from issuing and promoting central bank digital currency (CBDC).

European Union

• Although there were no legislative updates this week, the European Commission and multiple national regulatory agencies are pushing for the implementation details of the MiCA regulation.
• MiCA clarifies stablecoin issuance requirements, asset service provider obligations, and anti-money laundering obligations, expected to be uniformly implemented across the region by the end of 2025.

India

• The Indian Ministry of Finance continues to promote international cooperation on the Crypto Asset Reporting Framework (CARF), planning to establish a tax information automatic exchange mechanism to regulate the cross-border flow of virtual assets.
• This mechanism will enhance tax audit capabilities for local exchanges and investors.

Pakistan

• Officially established the "Virtual Asset Regulatory Authority (PVARA)" and launched a licensing system for cryptocurrency trading and custody.
• The new system allows regulated entities to test crypto products in specific "regulatory sandboxes," including exchanges, custody, and payment services.

Iran

• The central bank has restarted the cryptocurrency trading licensing program.
• Requires trading platforms to connect to the national regulatory API system to achieve data transparency, user real-name compliance, and transaction tracking.
• This policy continues Iran's regulatory attitude of coexistence between "restriction and licensing."

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。