TRON Industry Weekly Report: BTC Consolidates, ETH Soars, JP Morgan & Samsung Invest in Canton Network

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 all-time 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 held a "Cryptocurrency Week," focusing on reviewing several policy frameworks. Such policy trends have significantly boosted Bitcoin prices and expectations for the legalization of the crypto market. Continuous institutional inflows and favorable legislation form 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 subsequent legislative developments 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 Track 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 Tracks and Potential Projects of the Week

1. Overview of Potential Projects

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

Introduction

Veda is a DeFi vault primitive, 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 leading market 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;
• Promoted 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 enables 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: Dynamically allocating capital to different yield strategies;
• Automated optimization: Continuously adjusting to achieve the best risk-return ratio;
• Rapid iteration: New vaults or strategy updates can be deployed in as little as 48 hours.

Core differentiating features:

• Protocol, asset, and chain agnosticism: Seamlessly operates across multiple blockchains (including EVM, SVM, MoveVM, etc.) and integrates with various DeFi protocols;
• Support for any complex strategy: By 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 most secure and 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. Its 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 (hook module, optional)
  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 address deposits and locking shares.
• Manager (asset management module)
  Responsible for rebalancing vault assets. Through Merkle proof mechanisms, it ensures that only authorized and predefined strategies are executed, thereby 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 checks, 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 yields 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 are retained 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 unlocking period). Note: Separating the withdrawal logic from the core vault logic has security advantages.
5. Every 24 hours, the Oracle updates the vault exchange rate through the Accountant, reflecting the interest or yields generated.

Commentary

As a native DeFi yield infrastructure, Veda possesses significant advantages in modularity, non-custodial nature, 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 multiple external modules and oracles may pose certain operational risks and synchronization challenges in extreme market conditions or inter-chain communication delays.

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

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
• Has an innovative architecture that enables multi-chain connectivity within the ecosystem

Core Features:

• 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 methods:

• 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 Layer-1 block generation.
• Define the eligibility 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 chains controlled by generators holding over 50% of Layer-1 generation balance.

Core Elements 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 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 installed act as consensus clients.

Rewards
By running nodes, you can earn rewards through the following means:

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 for ensuring 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 Layer-1 block production through generator commitments. Its core features include:

• Fair block generation: Generators have equal opportunities to participate in block creation.
• Fork resolution: Prioritize chains controlled by generators holding 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, supporting complex transaction operations and scalability testing.

Commentary

Unit Zero's advantages lie 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, its node structure is flexible, allowing developers to conduct risk-free development and debugging between the mainnet and testnet.

However, its 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 Overview of Key Projects of the Week

2.1. Detailed Analysis of Canton Network — an institutional-grade Layer-1 blockchain network governed by financial institutions, supporting atomic transactions and privacy protection, raising $135 million

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 executes 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 co-governed by multiple financial institutions, supporting atomic 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 between participants. It possesses private chain-level privacy protection capabilities on a public chain network, with various applications sharing a common ledger view. 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, operation, 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 easily understand and maintain.
• DAML supports application interoperability, allowing workflows to be combined into more complex processes, even if these workflows have been deployed across different networks. Any participant can unilaterally extend functionality by combining existing workflows, promoting natural growth of the ledger and helping manage complexity. DAML enables workflow combinations across application networks while ensuring confidentiality and authorization requirements for each application.
• DAML supports interoperability with other systems through integrated tools, including automatic binding generation for common programming languages, bridging tools for connecting to other blockchains, and providing common standards and domain-specific libraries.

Contracts
DAML defines a "contract" as a codified agreement reached by multiple participants in the network regarding a 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 jointly signed by a consortium of multiple institutions.

Transactions
Contracts are created in a transaction and are considered "effective" once created. A subsequent transaction 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 portions of the transaction relevant to them based on the privacy definitions of their respective contracts, a mechanism known as "sub-transaction privacy." Each participant can only see and verify the transaction segments 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, once a UTXO is referenced in Bitcoin, the system must consider it as used (archived).

Additionally, the transaction structure in DAML is tree-like, supporting workflow combinations. The tree structure of existing workflows can be integrated as subtrees in 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 part 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 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, eliminating the need 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. Whether the transaction is consistent with the current view;
2. Whether the transaction complies with the logic written in the smart contract;
3. Whether the transaction has 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:

• Parameters (Arguments): The data stored by the contract.
• Operation Options (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 operation options.
  A participant can delegate their permissions to others to perform specific actions. When a transaction uses a certain party's permissions, that party will be able to see that operation.

• Constraints: Conditions that all instances of that 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 fragment" 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 transactions occur, only the relevant parties update their respective ledger views.

This presents a challenge: if the records of smart contracts are dispersed across many ledgers visible only to specific participants, how can the accuracy and consistency of these contract records be ensured? DAML addresses this issue by introducing the concept of a "virtual global ledger." All participants' ledger views are considered subsets 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 each properly functioning node's ledger view is a valid subset of this global ledger.

Moreover, DAML's design supports a "network of networks" architecture. Each participant can connect to one or more subnets, while the Canton protocol can synchronize digital asset transactions across 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 guarantees 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 its 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.

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, which achieves distributed synchronization domain through joint deployment. Anyone can deploy new sync domains to meet performance, compliance, and regional 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 connect with each other through Canton service providers (CSP) or virtual CSPs (vCSP) formed by 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 any 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 parallelly synchronize this data. 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 atomic transactions across multiple applications 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 for 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 Trimming and Compliance:

Canton supports the trimming and redaction of historical data, allowing node operators to balance auditing capabilities and compliance requirements (such as GDPR's "right to be forgotten") 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 trimmed, 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 deterministic transaction processing. The ordering protocol can be executed by centralized CSPs or run within distributed sync domains of virtual CSPs, secured by Byzantine Fault Tolerance (BFT) algorithms.

Figure 5: Atomic asset exchange transaction. The asset exchange is successful only when 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 can only 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 within their respective CSPs, while currency holders can still atomically exchange currencies in cross-sync-domain transactions.

While, like other blockchains, a single global sync domain can achieve global composability, having multiple sync domains offers 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, improving throughput; critical workflows can utilize new sync domains with restricted access; and different sync domain operators may have different fee structures. In the above example, local currency transactions are processed within the jurisdiction of the central bank.

However, multiple sync domains also present challenges for cross-domain workflow combinations. In DAML, combining workflows means that contracts synchronized by different sync domains can be jointly used 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 one common sync domain, and changes to the contracts 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.

Summary

Canton, as a privacy-preserving open-source blockchain protocol supporting multiple sync domains, excels in its unique virtual global ledger model and sharded storage design, ensuring data privacy and security while enhancing system scalability and performance. Additionally, its flexible sync domain architecture supports cross-domain atomic transactions and network interoperability, adapting to diverse application scenarios and compliance needs. However, potential disadvantages may include higher system complexity, stricter collaboration 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. Price Trends of Spot BTC vs ETH

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. Summary of BTC Layer 2 for the Week

1. Bitcoin Hyper Launch

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

1. Lightning Node Revenue Requires Active Management

• Reports indicate that Lightning nodes cannot be operated in a "free-range" manner.
• Nodes need to regularly optimize fees and ensure online presence 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 scale significantly.

1. LayerBTC Release Plan

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

1. Lightning Enterprise Expansion

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

2.2. Summary of EVM & Non-EVM Layer 1 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, fully returning 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, virtualizing cross-chain asset processing 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 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 Rollup Rapid Deployment Tools

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

2.3. Summary of EVM Layer 2 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 low-cost advantages. Although daily active users are still fewer than 150, the ecological development shows a positive trend.

2. Polygon Significantly Optimizes: 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 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, capable of "one-click elastic deployment of 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-speed 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, the 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.

This week (July 21 - July 25), important macro data release nodes include:

• July 23: U.S. EIA crude oil inventories 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 legitimacy to federal-level regulation, clearing obstacles for institutional adoption.
• "Crypto Week" Three Bills Progressing
• The House of Representatives passed three key pieces of cryptocurrency legislation:

• GENIUS Act: Standards for stablecoin regulation.
• 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 are 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 the requirements for stablecoin issuance, obligations of asset service providers, 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 auditing capabilities for local exchanges and investors.

Pakistan

• Officially established the "Virtual Assets 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 resumed its 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."