TRON Industry Weekly Report: Limited Impact of Geopolitical Crisis, BTC Steady at 100,000, Rise of BTC Native ZKP DeFi Protocol Ducat

I. Outlook

1. Macroeconomic Summary and Future Predictions

In May, the CPI year-on-year growth slowed to 3.3%, with zero growth month-on-month. The core CPI was 3.4% year-on-year, with a month-on-month increase of 0.2%, marking the lowest level in three years. This indicates a relief in inflationary pressures; however, the Federal Reserve still considers inflation levels to be high and requires more data to support any interest rate cut decisions.

The Federal Reserve maintained the federal funds rate at 4.25%-4.5%, expecting only one rate cut this year. Officials are cautious about rate cuts, emphasizing the need for more "good data" showing inflation improvement before easing monetary policy.

2. Market Movements and Warnings in the Crypto Industry

Last week, both Bitcoin and Ethereum faced resistance after multiple attempts to break key resistance levels (approximately $110,000 for Bitcoin and $2,850 for Ethereum), primarily due to rising market risk aversion triggered by geopolitical crises, leading to capital outflows from crypto assets and short-term price pressure. The escalating conflict between Israel and Iran has driven up gold and the dollar, suppressing the performance of risk assets. Technical indicators show that both Bitcoin and Ethereum are in critical pressure zones, with profit-taking by bulls and increased activity from bears, suggesting a potential short-term consolidation. Nevertheless, institutional capital continues to flow in, and the long-term fundamentals still support the market. Future attention should be paid to the impact of geopolitical situations and macroeconomic changes on prices.

3. Industry and Sector Hotspots

The DeFi protocol Ducat aims to achieve the decentralized vision of stablecoins through Bitcoin's native ZKP, providing a stablecoin solution that integrates Bitcoin's censorship resistance with decentralized native collateral assets. The new DeFi protocol Mirage, based on the Move framework, enhances stable returns through the yield-bearing stablecoin mUSD while ensuring user risk protection.

II. Market Hotspot Sectors and Potential Projects of the Week

1. Performance of Potential Sectors

1.1. Analysis of the DeFi Protocol Ducat Achieving Decentralized Vision of Stablecoins through Bitcoin's Native ZKP

++Introduction++

The Ducat protocol manages the issuance and redemption of UNIT collateral debt positions (CDPs) through Bitcoin's native zero-knowledge proofs. Its governance token DUCAT is designed for decentralization, aiming to provide a stablecoin solution that integrates Bitcoin's censorship resistance with decentralized native collateral assets.

The Ducat protocol addresses the centralization issues in the current stablecoin market by building a Bitcoin-native, self-custodial, permissionless smart contract system, aligning with Bitcoin holders' preferences for security and autonomy.

++Architecture Overview++

++1. UNIT++

UNIT is designed as a collateral debt position (CDP) supported by BTC, aiming to soft peg its price in the range of 1.01--1.04 UNIT/USD before transaction costs to support responsible leveraged financing activities in the BTC-Fi ecosystem.

The core value of UNIT lies in providing borrowers with a conservative and robust on-chain leverage tool, maintaining a target collateralization rate between 135%--160%. Initially, "loans" in the form of UNIT will have the following characteristics:

• 0% interest,
• 1% redemption fee,
• floating liquidation fee rate.

All these parameters, along with any future mechanisms, will be collectively decided by DUCAT holders through governance processes.

The Ducat protocol plans to accept other BTC-native collateral assets with complete price cycle history in the future, but in the short term, BTC remains unmatched in liquidity and volatility characteristics among non-fiat crypto assets.

We choose a 135%--160% collateralization rate to pursue capital efficiency while resisting BTC's historical volatility during the Bitcoin block time (approximately 10 minutes).

Exogenous Collateralization is currently the most reputable risk structure for stablecoins in the market.
Stablecoins or similar derivatives that remain robust under significant market pressure typically share the following characteristics:

• They are either "externally over-collateralized" models using tokens with market capitalizations far exceeding that of the stablecoin protocol, where the protocol has little to no influence on the collateral,
• Or they are a rare few that adopt extremely high ratios of "internally over-collateralized" CDP mechanisms with strict control over debt generation.

++2. Ducat Workflow++

Bitcoin is designed as a value storage tool and settlement layer, creating opportunities for complementary systems that provide price stability while retaining Bitcoin's security and decentralization features. The Ducat protocol leverages the capabilities brought by the Taproot upgrade to create secure and auditable primitives on Bitcoin's layer (L1) through Tapscript script paths controlled by governance consensus, achieving near-smart contract functionality without relying on any layer two networks (L2).

As the Bitcoin-native economy (including L1 protocols and L2 networks) rapidly develops, the market urgently needs a stable value account unit with complete decentralized collateral management capabilities that does not rely on specific Bitcoin L2 security assumptions.

The Ducat protocol consists of eight core components:

• UNIT: A debt token supported by BTC over-collateralization, soft pegged to the dollar.
• MPC Network: A network composed of decentralized nodes (referred to as "guardians" in the document) that will strictly, blind-sign, multi-sign, and broadcast the partially signed Bitcoin transactions (PSBT) submitted by users.
• Transaction Builder (ClientSDK): Builds PSBT transactions that comply with Ducat protocol rules, manages wallet signatures, and communicates with the MPC network.
• Standard Reference Satoshi (CRS): Satoshis marked by inscriptions, pointing to key parameters and governance mechanisms of the Ducat protocol (i.e., "contracts"). Ducat includes the following key CRS:
• Protocol CRS: Regulates UNIT's risk and collateralization parameters;
• Guardian CRS: Defines the operators of the MPC network;
• Oracle CRS: Lists the oracle solutions accessed by the protocol;
• Minting CRS: Controls the minting and issuance of UNIT (including UNIT Etcher addresses);
• Main CRS: Aggregates all CRS pointers for overall protocol reading.
• On-chain Data Record Structure (Records): Closely related to CRS, it is a set of data stored on-chain and referenced:
• Account Records: Defines accounts holding UNIT, associated with the Mint contract;
• Exchange Records: Defines the public keys and host addresses of exchanges;
• Guardian Records: Defines the public keys and host addresses of guardians;
• Term Records: Defines specific term values;
• Vault Records: Defines user vault configurations, associated with account records;
• Vault Tokens: Held by user wallets, containing location information pointing to corresponding vault records and user-configurable settings;
• Master Contract: References the inscription IDs of all contracts, defining which contracts are the official versions in the protocol.
• Bitcoin Collateral Debt Position (BCDP): Refers to the mechanism where users pledge (custody) BTC in the protocol according to the vault CRS to mint and collateralize UNIT.
• Reserve Mechanism (The Reserve): A reserve fund owned by the protocol to absorb bad debts, protecting the overall vault pool's security in extreme scenarios where auction interest is insufficient, and collateral sales do not cover debts.
• Validation Layer: Similar to Bitcoin core node software, used to parse and verify the legality of all protocol-related transactions, automatically identifying and excluding any operations that do not comply with protocol rules. Validation content includes:
• DUCAT Account UTXO: Used for minting DUCAT;
• DUCAT Spend UTXO: Used for the use of DUCAT governance tokens;
• UNIT Account UTXO: Used for minting UNIT;
• UNIT Spend UTXO: Used for the use of UNIT stablecoins;
• Vault Transactions: Locking BTC to exchange for UNIT;
• Contract Transactions: Defining variable parameters of the protocol;
• Record Transactions: Storing data referenced by contracts;
• Proposal Transactions: Submitting modification proposals for contracts;
• Voting Transactions: Using DUCAT to vote on proposals.

All components of the protocol will be open-source, and third-party independent, reputable oracle providers will be introduced to provide price signals to the liquidation engine in an off-chain but verifiable manner.

++3. Architecture Diagram++

The architecture of the Ducat protocol can be broken down into the following illustrated process, showing the various steps a user experiences when attempting to borrow UNIT.

In this, the MPC Network acts as a distributed co-signer, aiming to solve the liveness problem that may arise in pure peer-to-peer networks. This network performs the following key tasks:

Verifying the validity of vault operation-related transactions;

Based on user signatures, co-signing transaction outputs;

Managing rune distribution, ensuring reasonable UTXO allocation for the protocol network and users;

Continuously monitoring whether the collateralization rate exceeds the threshold set by the protocol;

Ensuring that returned UNIT tokens are destroyed;

Verifying transaction order and its compliance with protocol standards.

Theoretically, the Ducat protocol could be entirely reconstructed as a pure peer-to-peer network without a "guardian network", operating in a more decentralized scenario.

++Commentary++

The advantage of the Ducat protocol lies in its native construction on Bitcoin's layer (L1), achieving a BTC over-collateralized stablecoin system without bridging or centralized custody. It integrates Bitcoin's censorship resistance, security, and programmability brought by Taproot, using the MPC network to realize transaction verification, signing, and collateralization monitoring, balancing decentralization and protocol liveness. Furthermore, the DUCAT governance mechanism ensures adjustable parameters, with high transparency and flexibility.

On the downside, Ducat currently relies heavily on the MPC network as an intermediary to ensure protocol operation, which, while solving the liveness problem of pure P2P networks, introduces new trust assumptions to some extent. Its smart contract capabilities are limited by Bitcoin's own programmability, which may affect the protocol's future complex expansion capabilities. Additionally, its initial asset type is singular (only supporting BTC collateral), limiting the flexibility of multi-asset use.

1.2. Interpretation of How the New Move-based DeFi Protocol Mirage Enhances Stable Returns through Yield-bearing Stablecoin mUSD While Ensuring User Risk Protection

++Introduction++

Mirage is building a modular currency system based on Move. Its core is a liquidity layer driven by synthetic assets, supporting the construction of various financial products. The Mirage team has developed a high-performance perpetual contract DEX (called Mirage Market), which also allows other protocols to build their products by accessing Mirage's liquidity.

The liquidity of Mirage comes from the minting mechanism of synthetic assets—users can mint corresponding synthetic assets by pledging high-quality assets. The first synthetic asset of Mirage is the stablecoin mUSD, which can be exchanged for other tokens and used within the Mirage ecosystem, such as serving as margin for the perpetual contract DEX.

Mirage is designed specifically for Move-based ecosystems, initially deployed on Aptos and Movement, providing speed and security rarely seen in the market, achieving near-instant transaction execution and extremely low fees, delivering a top-notch user experience.

++Architecture Overview++

++1. Mirage Asset Types++

Mirage assets are pegged to the prices of real-world assets (RWA), covering various categories from fiat currencies to Bitcoin. Users can mint Mirage assets by providing high-quality collateral (such as USDC and Aptos (APT)), forming over-collateralized debt positions (CDP).

In the initial phase, Mirage will launch its first asset mUSD, followed by mAPT:

• mUSD ------ Mirage Dollar, serves as the margin asset for the Mirage perpetual contract DEX. The minting party of mUSD acts as the counterparty to traders, thus earning most of the revenue from protocol fees. These fees will be used to repay the mUSD debt held by users, gradually unlocking the pledged assets. In this sense, mUSD resembles a "self-repaying" stablecoin loan mechanism.
• mAPT ------ Mirage Aptos, functions similarly to mUSD but is primarily used for settling Aptos options trades rather than perpetual contracts. We plan to accept liquid staking assets from top Aptos ecosystems (such as Amnis and Thala) as collateral, allowing users to further leverage the returns generated from their staked APT while earning options trading fees.

Additionally, Mirage assets can be used in various leverage and hedging strategies within the Aptos ecosystem, greatly expanding their applicability and flexibility as financial tools.

++2. Vaults++ Users mint Mirage assets by locking collateral in vaults.

Each vault essentially represents an over-collateralized debt position, containing one type of collateral asset and its corresponding minted Mirage asset. Each combination of collateral and Mirage asset has its specific collateralization ratio (c-ratio) parameter. For example, highly correlated combinations like USDC/mUSD have lower collateralization ratio requirements, while combinations with lower correlation, like APT/mUSD, will have relatively higher requirements.

When a user's collateralization ratio falls below the target value, their vault will face liquidation risk. Anyone can execute liquidation operations, and the liquidator will receive a liquidation reward. The Mirage team has developed and open-sourced liquidation software, allowing anyone to use this tool to become a liquidator, or you can develop or modify existing liquidator code yourself.

Each vault itself is a digital asset token, meaning vaults can be transferred between accounts, traded on secondary markets, and easily composable with other protocols. This greatly enhances users' flexibility in position management while allowing other market participants to take over related positions at fair prices. From a portfolio management perspective, users can also directly view their held vaults in their wallets.

++3. Peg Mechanism++ Maintaining price peg is crucial for synthetic assets. To this end, Mirage implements a series of mechanisms to ensure its assets remain stable and robust.

First, all Mirage assets always maintain over-collateralization. This provides protection for the protocol during market volatility, ensuring system stability and preventing chain liquidations.

While the over-collateralization mechanism can ensure price peg at the protocol level, Mirage assets may still face significant trading pressure in the open market due to their wide applicability. Taking mUSD as an example:

• Buy Pressure: Caused by traders exchanging for mUSD. mUSD is used as margin in the Mirage perpetual contract market, making it essential for opening trades.
• Sell Pressure: Caused by liquidity providers (LP) exchanging their minted mUSD for other tokens.

To reduce slippage caused by one-sided trading or insufficient liquidity, mUSD will be placed in highly correlated liquidity pools, but even so, excessive buy and sell pressure in the market may still lead to temporary de-pegging of mUSD. At this point, the arbitrage mechanism will come into play to restore the price peg:

• mUSD de-pegged above $1: Users can mint mUSD at a fixed price of $1 within the Mirage protocol and sell it on the market for more than $1, creating sustained sell pressure until mUSD is re-pegged.
• mUSD de-pegged below $1: Users can repurchase mUSD at a price below $1 to repay previous loans, generating buy pressure to stabilize the price.

This mechanism encourages users to participate in arbitrage, achieving personal profit while maintaining the price peg of mUSD.

++4. Yield Strategies++

Mirage assets not only function within the Mirage protocol but can also be used in various yield strategies within the Aptos ecosystem. Here are a few simple strategies for obtaining higher yields using mUSD (note: listed APRs may change at any time):

1. Use Aries Market to Increase USDC Yield

Strategy Flow: Pledge assets (USDC or APT) → Mint mUSD → Exchange mUSD for USDC → Deposit USDC in Aries Market for additional yield.

Current Yield:

• USDC base annual percentage rate (APR): 3.77%
• APT incentive reward: 15.40%
• This is one of the most attractive yield strategies for stablecoins in Web3.

2. Use Amnis Finance for Liquid Staking and Airdrop Strategies

Strategy Flow: Pledge assets → Mint mUSD → Exchange mUSD for APT → Deposit APT in Amnis Finance and participate in its liquid staking.

Current Yield:

• Liquid staking APT annual yield: 11.12%
• Earn $AMI token airdrop points.
• Mirage is collaborating with Amnis to support liquid staking APT as collateral in the future.

3. Use Thala Labs for Leveraged Stablecoin Strategies

Strategy Flow: Loan mUSD to the Thala ecosystem and deposit it into multiple yield pools.

Current Yield:

Annual yields across different pools range from 20% to 140%, depending on specific pools and risk preferences.

Mirage is collaborating with Thala to plan support for the following assets as collateral:

• MOD stablecoin
• THL governance token
• Liquid-staked APT

4. Use Merkle Trade for Leveraged Contract Yield Strategies

Strategy Flow: Pledge assets → Mint mUSD → Exchange mUSD for USDC → Deposit USDC in Merkle Trade to obtain its LP tokens.

Current Yield:

• LP annual yield: 50%
• Additional rewards: LP incentives + MKL tokens.
• This strategy allows you to earn fees from two perpetual contract DEXs simultaneously.

Advanced: Circular Pledge + Leverage Strategy

Users can also strategically pledge assets and "circularly" mint mUSD (using the exchanged assets to continue pledging), deploying more complex leverage or hedging strategies. Meanwhile, the debt from mUSD loans will be passively repaid as the strategy generates returns, further increasing the overall APR.

++5. Mirage Market++

Mirage Market is a decentralized perpetual contract exchange that offers an easy-to-use, no-slippage trading experience, with a wide range of tradable assets, including cryptocurrencies, commodities, and fiat currencies, and will even support stocks in the future.

The platform has all the core features traders expect:

• High leverage
• Market orders and limit orders
• Take profit and stop loss functions
• Built-in cross-chain bridge and exchange functions
• High-frequency new asset listings, keeping pace with rapidly changing market dynamics

Leveraging the high performance of the Aptos blockchain and adopting a fair fee structure, Mirage provides the fastest and cheapest perpetual contract trading experience. Compared to mainstream platforms like GMX, users can enjoy up to 20 times lower fees, faster execution, and zero slippage trading.

To trade on the Mirage Market, users need to hold mUSD in their wallets, with all transactions settled in mUSD. The platform's built-in exchange function allows traders to easily obtain and convert mUSD without needing to mint it themselves, enhancing trading convenience.

++6. Mirage Swap++

Mirage Swap is the core component of the Mirage protocol used for efficiently trading Mirage assets with other Aptos tokens. Users can complete exchange operations natively on the platform or through aggregators like SwapGPT.

In the initial launch phase, Mirage Swap will include the following three incentivized liquidity pools:

• mUSD/USDC --- High correlation liquidity pool
• mUSD/APT --- Constant product pool (common AMM structure)
• mUSD/MIRA --- 80/20 weighted Balancer-style pool

Users can provide funds to these liquidity pools and stake them in Oasis for additional rewards.

Regarding fees:

• For stablecoin pairs like mUSD/USDC, the trading fee is 0.05%
• For more volatile trading pairs, the fee is 0.30%
• Mirage Swap aims to provide robust trading infrastructure for Mirage assets while offering rewards and low-cost trading experiences for liquidity providers and traders.

++7. MIRA Token++

MIRA is the utility token of the Mirage protocol, primarily used for protocol governance and liquidity incentives. The protocol adopts a vote-escrow model, aiming to align liquidity providers (LP) with the long-term development goals of the protocol.

10% of the protocol's revenue will be used to buy back and burn MIRA, controlling the total token supply and enhancing its value.

veMIRA

veMIRA is an important component of the Mirage protocol with multiple uses:

• Participate in Mirage governance voting
• Enhance rewards for liquidity provision
• Reduce trading fees
• veMIRA holders will receive a fixed proportion of MIRA inflation rewards

Users can obtain veMIRA by locking MIRA, with longer lock-up periods yielding more veMIRA:

• Locking 100 MIRA for 6 months → Obtain 100 veMIRA
• Locking 100 MIRA for 3 years → Obtain 300 veMIRA
• The longer the lock-up period, the greater the governance voting weight and economic incentives.

The issuance logic of the MIRA token is designed around a sustainable inflation mechanism and fair distribution principles. Complete details regarding the token economic model and incentive schemes will be announced before the mainnet launch.

++Summary++

Mirage's advantages lie in its construction on the Move ecosystem (such as Aptos and Movement), offering extremely high execution speed and security; its modular architecture makes it a powerful liquidity layer supporting synthetic assets and diversified financial products (such as stablecoin mUSD, futures DEX, and composable Vaults). The over-collateralization mechanism of mUSD, the arbitrage stabilization mechanism, and diversified yield strategies and ecosystem collaborations (such as Amnis, Thala, Merkle) enhance its stability and practicality. The governance mechanism achieves long-term incentives and community leadership through MIRA and veMIRA.

Disadvantages include: as a newer protocol, its risk resistance still needs to be validated by the market, especially regarding liquidation efficiency and peg stability under extreme market conditions; additionally, the ecological value of mUSD heavily relies on Mirage's own product closed loop, and external acceptance and scalability still require ongoing promotion; meanwhile, the Move ecosystem is still in its early stages, with a smaller ecosystem scale and developer base compared to Ethereum, which may limit the protocol's early growth speed and liquidity depth.

2. Detailed Project Focus of the Week

2.1. Detailed Explanation of Impossible Cloud Network (ICN), Integrating Next-Generation Cloud Services, AI Intelligence, Enterprise Software, and Digital Ecosystems as a Web3 Foundation Layer

++Introduction++

Impossible Cloud Network (ICN) is building the foundational layer for the next generation of the internet. ICN challenges the dominance of centralized tech giants, unlike various DePIN projects that operate independently. ICN introduces a completely open, multi-service, permissionless, and composable cloud infrastructure capable of integrating storage, computing, and networking at scale. Our enterprise-grade decentralized architecture ensures high performance, security, and censorship resistance, making the Web3 experience as seamless as Web2. With real-world application deployment and pragmatic decentralization strategies, ICN is poised to become the foundational layer for the future internet, powering next-generation cloud services, AI intelligence, enterprise software, and digital ecosystems.

++2. Architecture Analysis++

++Core Components++

• Smart Contracts: Execute ICN's economic and resource allocation systems while implementing performance verification logic.
• ScalerNodes: The basic resource unit nodes in the protocol. Physical servers with specific hardware specifications connected to the network by hardware providers.
• Daemon: The core diagnostic agent responsible for resource configuration, telemetry monitoring, and hardware responses. The deployment of ScalerNodes requires the installation of Daemon.
• HyperNodes: Independent verification nodes responsible for verifying the quality and performance of hardware resources. Reports from HyperNodes are evaluated by ICN smart contracts to ensure builders receive the expected service quality.
• Satellite Network: Ensures the availability and integrity of off-chain challenge data. In the current version, the satellite network is deployed as part of system initialization.
• Services & Apps: Builders reserve network capacity by ScalerNode units and deploy services and applications at scale.

++Protocol Lifecycle++

The ICN architecture achieves efficiency and auditability through streamlined workflows:

• Resource Provisioning: ScalerNodes connect to the protocol with specific hardware categories and deploy Daemon.
• Resource Reservation: Builders reserve resource capacity by ScalerNode units in specific areas through the console and gain hardware access to deploy services.
• Performance Monitoring: HyperNodes continuously audit the performance metrics of Daemon and submit reports off-chain to the Satellite Network. Daemon and HyperNodes synchronize execution of challenges from smart contract events through the Indexer.
• On-chain Settlement: Smart contracts settle penalties and rewards based on challenge results from the Satellite Network and complete verification on-chain.

++1. ScalerNode Network++

Hardware Classes ICN defines hardware classes as combinations of hardware resources optimized for specific use cases. By standardizing these classes, ICN achieves uniformity in diverse hardware configurations from different vendors. For example, when providing storage-optimized ScalerNodes, ICN sets dedicated configurations for storage capacity, disk I/O operations, and vCPU counts. In contrast, ScalerNodes used for accelerating computation focus more on the number and model of GPUs and memory allocation.

ScalerNodes with the same hardware class have equivalency in hardware resources, such as identical disk counts and storage capacities. This consistency can be ensured even if devices come from different manufacturers, although performance may vary slightly. If significant performance discrepancies arise between ScalerNodes, they will be classified into different hardware classes.

During registration, hardware providers assign specific hardware classes to ScalerNodes. These nodes are then grouped according to their hardware classes. Currently, ICN only offers one storage class to simplify initial deployment and focus on optimizing storage capabilities.

Regions and Clusters

ScalerNodes register in different regions based on their geographical locations to ensure data localization and compliance with regional regulations. Within the same region, ScalerNodes are assigned to different clusters based on their hardware classes and other economic factors.

• Region: The highest level of geographical scope, representing a city or large area. When hardware providers register new ScalerNodes, they select a region from the options provided by ICN. Within the same region, all ScalerNodes share certain economic parameters, such as subsidy rewards or staking requirements for specific hardware classes.
• Cluster: A logical grouping within a region that contains ScalerNodes of the same hardware class provided by one or more hardware providers. Each cluster defines the maximum price that ScalerNodes of that hardware class can set. Builders reserve resource capacity at the cluster level by ScalerNode units.

ScalerNode

Hardware providers are responsible for managing and configuring physical servers and networks, ensuring ScalerNodes can be securely accessed remotely. The main responsibilities of hardware providers include:

Physical host maintenance, including firmware updates and maintenance of additional devices (such as storage drives, memory, GPUs, etc.);

Configuring boot via PXE or iPXE for automatic booting of the host operating system;

Configuration and management of internal networks, including routers, switches, and firewalls;

External network connections to ensure servers can be accessed from the internet.

When registering ScalerNodes in ICN, hardware providers must provide the following parameters:

• Hardware Class: The hardware type class to which the ScalerNode belongs;
• Location: The geographical location of the ScalerNode, following ISO 3166 standards;
• Capacity: The total available capacity of the ScalerNode under a specific hardware class;
• Rewards Share: The proportion of rewards shared with delegators, ranging from 0% to 100%;
• Reservation Price: The price calculated per capacity unit per day, priced in ICNT;
• Maximum Booking Duration: The maximum reservation period, defaulting to 180 days.

As part of the registration process, hardware providers must provide staking guarantees for their ScalerNodes (see "Hardware Provider Staking Requirements" section for details).

Daemon

Once on-chain registration and staking are completed, ScalerNodes can enter the configuration phase and install Daemon to connect to the ICN protocol. Daemon is the core diagnostic agent responsible for collecting and reporting data related to hardware performance, sending it to the HyperNode network.

The steps following registration include:

1. Capacity Verification: Verifying the capacity declared by the registered ScalerNode;
2. Daemon Installation: Installing the required Daemon software on the ScalerNode;
3. Cluster Allocation: Allocating the ScalerNode to a specific cluster in its region based on hardware class.

Once verified and activated on-chain, the ScalerNode can begin earning capacity rewards and be made available for builders to use. The deployed Daemon will continuously initiate challenges with the HyperNode network and report relevant telemetry data. Hardware providers can access this information via the console for real-time monitoring and troubleshooting.

++2. HyperNode Network++

The HyperNode network operates in a decentralized manner, relying on community members across the global internet. A single HyperNode operator can deploy multiple HyperNodes, with each node requiring at least one ICN Link (ICNL) to be staked for activation. HyperNodes regularly initiate cryptographic signature challenges to ScalerNodes to monitor their key performance indicators.

HyperNode

HyperNode operators are responsible for registering and managing HyperNodes, ensuring nodes can be accessed from the internet. When registering a HyperNode, the following information must be provided:

• Address: The blockchain address of the HyperNode. The private key of this account is used to sign challenge requests exchanged between Daemon and HyperNode.
• Location: The geographical location of the HyperNode, following ISO 3166 standards.
• Endpoint: The fully qualified domain name (FQDN) or IP address that the HyperNode can be accessed from the internet.

Once registered, HyperNode operators must start the node and pass the private key as a parameter. Thereafter, when one or more ICNLs are staked to that HyperNode, the node is activated and begins initiating challenges.

Challenge Mechanism

Challenges in the protocol are conducted periodically within fixed time intervals called "eras." Each era lasts approximately one hour, measured in block counts. The following diagram illustrates the process of challenge execution within an era.

To synchronize the execution of challenges, both Daemon and HyperNode obtain data from the Era Manager smart contract. This data includes the number of blocks for the era and the starting block, allowing for an approximate calculation of the era's end time.

During each era, Daemon initiates a challenge to every active HyperNode in the ICN network. The specific process is as follows:

1. Daemon sends a challenge request to HyperNode 1;
2. HyperNode 1 signs the challenge and returns the response to Daemon;
3. Both Daemon and HyperNode submit reports to the Satellite Network (for report details, see the "Satellite Network" section).
4. The ICN protocol currently assesses the availability of ScalerNodes as the proportion of time Daemon can access and respond correctly during the challenge process. To achieve this, HyperNodes must be accessible via the internet to receive challenges from Daemon. Each HyperNode must respond to one availability challenge from each ScalerNode during each era.

++3. Satellite Network++

In ICN, all availability challenges require both ScalerNode and HyperNode to jointly submit reports to the Satellite Network. By using the Satellite Network, report data can be stored off-chain for a predetermined duration, ensuring accessibility during this period and securely deleting it after the deadline.

The current availability report includes the following information:

• Report Originator: The type of node submitting the report (ScalerNode or HyperNode);
• Originator Version: The software version running on the reporting node;
• Era ID: The era number during which the challenge was initiated;
• ScalerNode ID: The unique identifier of the ScalerNode initiating the challenge;
• HyperNode ID: The unique identifier of the HyperNode responding to the challenge;
• Signatures: Signature records from both ScalerNode and HyperNode, including corresponding public keys.

++4. Smart Contracts++

Smart contracts implement and enforce the economic model of ICN, responsible for resource allocation management and performance verification logic execution. They automate and standardize transactions and interactions within the ICN ecosystem, executing operations such as reward distribution, payment processing, or performance verification automatically based on preset conditions. This automation eliminates the need for intermediaries, minimizing the potential for human error or manipulation, thereby building a transparent and trustworthy system.

ICN's smart contracts adopt a multi-implementation proxy architecture, offering the following advantages:

Unlimited Code Deployment Size: Breaking down large, complex logic into smaller, more manageable parts effectively circumvents the gas limit issue on contract code size.

• Modularity: Related functional logic is divided into independent contracts that can be upgraded individually without affecting each other. This separation of concerns design facilitates updates or modifications to a component without impacting other parts of the system. For example, updating one module will not cause errors in components dependent on the old version.
• Extensibility: When new functional requirements arise, modules can be added to the system by deploying new contracts, allowing for smooth expansion of functionalities and enabling the smart contract system to evolve and grow gradually.
• Structured Organization of the Storage: Organizing data storage in a hierarchical manner facilitates management and maintenance of complex state transitions.
• Improved Security through Compartmentalization: Each contract is responsible for a specific function within the system, limiting potential vulnerabilities within their respective modules, reducing the attack surface, and making it harder for hackers to exploit system weaknesses.
• Enhanced Maintainability and Debugging Capabilities: Each module is independent and self-contained, allowing developers to focus on a specific part of the system without being hindered by complex interactions between multiple components. This approach improves development efficiency, code quality, and accelerates debugging processes.

The ICN smart contract modules are divided as follows:

• Access Control: Manages and regulates who has permission to interact with various parts of ICN. The main functions of this module include granting and revoking role permissions for specific accounts.
• ICN Registry: Contains all functions related to the registration and removal of various entities in ICN (such as regions, clusters, hardware providers, ScalerNodes, service providers, HyperNodes, etc.), as well as functions for updating parameters of these entities (e.g., updating the reservation price of a ScalerNode).
• Booking Manager: Controls all operations and related parameters associated with resource reservations within ICN.
• Era Manager: Responsible for tracking eras within ICN and allowing updates to the duration of eras (measured in block counts).
• HP Delegation: Contains all functions related to ScalerNode staking and network staking of ICNT, including locking, claiming, and withdrawing rewards.
• HP Rewards: Provides calculation functions for capacity and utilization rewards for ScalerNodes, as well as reward calculations for delegators based on the rewards sharing mechanism.
• Link Rewards: Manages operations related to ICN Link rewards, such as claiming and withdrawing rewards.
• Link Staking: Contains functions related to staking and unstaking ICN Link, supporting updates to related parameters, such as the minimum staking period or the maximum number of ICN Links that can be staked by a single HyperNode.
• Slashing: Contains functions related to penalizing (forfeiting) ScalerNodes for misconduct.

++Summary++

ICN (Impossible Cloud Network) provides a decentralized, modular, and composable cloud infrastructure that integrates storage, computing, and network resources, offering high performance, security, and censorship resistance as foundational support for the next generation of the internet. Its advantages include: open architecture, permissionless access, automated execution of economic models via smart contracts, high scalability, and maintainability, making it suitable for supporting AI, Web3, and enterprise-level applications. By standardizing hardware classifications and regional deployments, it ensures resource consistency and compliance while introducing a dual-node verification mechanism (ScalerNode and HyperNode) to enhance network credibility. However, its disadvantages include high system complexity, higher deployment thresholds, and initial support for only a single storage-type resource, with the ecosystem still in its early stages, posing high demands for large-scale application and operational capabilities.

III. Industry Data Analysis

1.1. Spot BTC vs ETH Price Trends

BTC

Analysis

This week's focus: Whether $103,000 can serve as the next support level for a pullback. If effective, a rebound to test the $110,000 threshold is expected; if it breaks, attention should shift to the previous low of $100,500. Note that as long as the price does not fall below the crucial $100,000 mark, the medium to long-term bullish outlook remains unchanged.

ETH

Analysis

This week's focus: ETH is currently operating at the bottom of an upward channel. If the lower boundary of the channel holds, a bullish outlook towards the middle of the channel is possible; if it breaks, watch for support around $2,440. If a rebound is hindered at the lower boundary, further declines towards $2,380 are anticipated.

2. Public Chain Data

2.1. BTC Layer 2 Summary

Analysis

Lightning Network: This month, transaction volume surpassed $3 billion for the first time, with network channel capacity stabilizing in the range of 4,400–5,600 BTC, indicating increasing payment availability and enterprise-level deployment trends.

Stacks: Featured at the virtual investor conference on June 5, the latest round of 5,000 BTC subscriptions for sBTC sold out within hours, and an incentive program was launched to attract institutional funds.

Liquid Network: The total locked value (TVL) of the sidechain solution steadily climbed to $3.27 billion, continuing to strengthen its role as a bridge for real-world asset tokenization.

Bitcoin Solaris: The new L2 project is in the final sprint of its pre-sale, promising over 10,000 TPS of high throughput, attracting market attention.

2.2. EVM & Non-EVM Layer 1 Summary

Analysis

Ethereum

• Price maintained in the range of $2,550–$2,600
• This week, ETF net inflows reached $240 million
• Whale holdings increased by 3.7%

Avalanche

• Driven by MapleStory Universe, this week’s trading volume reached a new high for 2025, hitting 5.8 million
• AVAX price briefly broke $20, but later retraced about 13% due to geopolitical concerns

Solana

• Daily maximum drop of 9.5%, but average daily trading volume remains between $4.5 billion and $6.3 billion
• Related ETF progress remains stable

Cardano (Non-EVM Layer 1)

• Price dropped 6% to $0.6412 due to controversy over a $100 million treasury proposal
• Subsequently rebounded 3% to $0.63035 after being included in the Nasdaq index, with trading volume surging by 68%

2.3. EVM Layer 2 Summary

Analysis

Here are the key dynamics of the week:

• Scaling Solution Dispute Escalates: Defi-Planet published an article comparing Optimistic Rollups and ZK Rollups in terms of costs, performance, and final confirmation speeds, emphasizing that both will coexist in the long term but adapt to different scenarios.
• Value Attribution Questioned: Coin World reported that despite EIP-4844 significantly reducing Layer 2 transaction fees, most fees are still captured by projects like Base and Arbitrum, failing to flow back to support ETH's value.
• Market Size Stabilizes with Minor Adjustments: According to CoinGape, as of June 9, the total market capitalization of top Layer 2 tokens was approximately $13.448 billion, with a weekly decline of only 0.65%, indicating strong resilience.
• Network Activity Continues to Rise: L2BEAT's weekly report shows that transaction volumes and user activity on major Rollup networks remain high, with slight increases in TVL and daily transaction counts, reflecting the growing dependence and user stickiness of Layer 2 on the Ethereum mainnet.

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

The May CPI data from the United States shows an overall CPI year-on-year increase of 2.4% (actual approximately 2.35%), with a month-on-month increase of 0.1%, both lower than expected. Energy prices fell 1% month-on-month, suppressing overall inflation, while food prices rebounded by 0.3% month-on-month; the core CPI remained flat at 2.8% year-on-year, with a month-on-month increase of only 0.1%, below market expectations, with core goods slightly dragged down by falling car prices and a slowdown in core service price increases. However, future inflation trends remain uncertain due to inventory changes and demand fluctuations.

Key macroeconomic data points for this week (June 16 - June 20) include:

• June 17: U.S. May retail sales month-on-month
• June 18: U.S. initial jobless claims for the week ending June 14
• June 19: U.S. Federal Reserve interest rate decision for the week ending June 18

V. Regulatory Policies

United Kingdom: This week, the UK's Financial Conduct Authority (FCA) announced plans to lift the ban on retail investors purchasing cryptocurrency exchange-traded notes (ETNs), allowing individual investors to trade such products on FCA-approved exchanges, but still warning investors about the potential risk of losing all funds and continuing to prohibit retail trading of crypto derivatives; this policy change is currently in the public consultation phase.

European Union: Under the newly implemented Markets in Crypto-Assets Regulation (MiCA), several large crypto companies, including Gemini, OKX, and Crypto.com, have obtained licenses to operate across the 27 EU countries; Malta was the first to approve, and Luxembourg also plans to approve Coinbase, but regulators express concerns about the rapid licensing in some countries.

United States: The U.S. Securities and Exchange Commission (SEC) Crypto Task Force held a public roundtable on June 9 titled "DeFi and the American Spirit," discussing regulatory directions for decentralized finance. Meanwhile, Congress continues to review the proposed CLARITY Act, which aims to delineate a regulatory framework for digital assets, but there are still disagreements on how to allocate powers between the SEC and CFTC.

China: The State Council's Financial Stability Development Committee explicitly listed "cracking down on Bitcoin mining and trading activities" as a key task during its policy meeting on May 21, triggering short-term panic among miners to accelerate migration. While some concerns have eased this week, regulation of OTC trading continues to strengthen; meanwhile, rumors about a complete ban on holding Bitcoin lack official evidence and are considered unverified media rumors.

Japan: The Bank of Japan (BOJ) reported that the proportion of cashless payments reached 42.8% in 2024, achieving the government's target a year ahead of schedule, and is promoting pilot projects for modernizing payment systems, including ongoing research and development of a digital yen, but no final issuance decision has been made. Regulators emphasize that future retail settlement systems must balance convenience and security to address competitive pressures from stablecoins and other countries' CBDCs.

Singapore: The Monetary Authority of Singapore (MAS) has ordered all companies registered in Singapore but providing digital token services overseas to cease such operations or apply for licenses by June 30, or face fines of up to SGD 250,000 and three years in prison; several unlicensed exchanges (such as Bitget and Bybit) have begun assessing exit plans.

Switzerland: The Swiss Federal Council adopted a draft this week to automatically exchange tax data on crypto assets with 74 cooperating countries starting in 2027, based on the OECD's Crypto-Asset Reporting Framework (CARF), to enhance cross-border tax transparency.

Spain: The Spanish Parliament passed a new law that will implement the EU's eighth administrative cooperation directive (DAC8) starting in January 2026, requiring platforms and individuals to report data on crypto asset holdings and cross-border transactions to improve tax reporting and enforcement efficiency.