Tron Industry Weekly Report: High unemployment rate and low price index in November solidify the bottoming trend of the crypto market, detailed explanation of the connection between BTC security and the native bridge BOB of ETH DeFi

# Outlook

1. Summary of the Macroeconomic Environment and Future Predictions

Last week, the macroeconomic environment in the United States was in a year-end lull and policy observation period. Against the backdrop of cooling employment and slowly declining inflation, there was a lack of new significant data last week, and the market mainly digested existing information. Influenced by holiday factors, economic activity and trading liquidity decreased, U.S. Treasury yields fluctuated at low levels, and the dollar was relatively weak. Meanwhile, U.S. stocks reached new highs supported by liquidity and expectations of a policy turning point, with the S&P 500 and Nasdaq hitting record levels, indicating a growing consensus among investors that "the tightening cycle has ended, and the economy is landing softly." However, the rise was more driven by valuation and expectations rather than improved data.

Looking ahead, the U.S. economy is likely entering a transitional phase of low growth, low inflation, and a relatively loose policy stance. If early-year data continues to confirm weakening employment and demand, expectations for the Federal Reserve to start cutting interest rates in early 2026 will be further strengthened; however, if service inflation or wages show volatility, the pace of easing may still be prolonged. For the market, there is a need to be cautious about volatility after liquidity returns at the beginning of the year: U.S. stocks will become more sensitive to data and policy after reaching new highs, and the trend will depend on whether the economic slowdown is mild and controllable.

2. Market Movements and Warnings in the Cryptocurrency Industry

Last week, the cryptocurrency market continued its weak and volatile pattern under the year-end holiday and low liquidity environment. Bitcoin was trading around $90,000, making several attempts to rebound but lacking sufficient volume, failing to follow U.S. stocks to new highs, and market differentiation further intensified. Institutional participation was low, ETF inflows were limited, and on-chain activity continued to decline, indicating that year-end funds were primarily in a wait-and-see and risk control mode. Altcoins performed significantly worse than BTC, with most sectors maintaining a downward trend, and only a few themes experiencing brief surges under extremely low liquidity, but with limited impact on overall sentiment, further revealing the divergence between the cryptocurrency market and traditional risk assets.

In terms of warnings, the current market remains in a sensitive phase of weak liquidity + year-end risk convergence. If Bitcoin cannot regain the $95,000-$100,000 range at the beginning of the year, the market may continue to maintain a bottoming state, and even face new selling pressure tests when liquidity returns. Meanwhile, if U.S. stocks experience volatility at high levels, it may amplify the downward movement of the cryptocurrency market through risk sentiment transmission. Overall, the cryptocurrency market is still primarily defensive in the short term, and real trend opportunities may need to wait for clearer macro-level easing to materialize and funds to flow back in.

3. Industry and Sector Hotspots

Led by GSR, Offchain Labs, and Frax, $7.6 million was raised to redefine DeFi lending protocols with high-speed liquidation and MEV recovery through Curvance, which provides lending services aimed at optimizing capital efficiency; a total of $8 million was raised for Solomon, a new generation stablecoin protocol that does not require collateral, does not require locking, and automatically earns yields, building a more composable dollar.

# Market Hotspot Sectors and Potential Projects of the Week

1. Overview of Potential Projects

1.1. Analysis of Curvance, which raised $7.6 million led by GSR, Offchain Labs, and Frax to redefine DeFi lending protocols with high-speed liquidation and MEV recovery

Introduction

Curvance provides lending services aimed at optimizing capital efficiency. The protocol supports high leverage without sacrificing lender security by combining a yield-generating collateral mechanism with a framework designed for high-speed liquidation.

By reducing liquidation costs to a small fraction of traditional protocols and achieving MEV recovery, Curvance can safely scale lending while maintaining high utilization rates and providing users with faster position response times under market pressure.

Protocol Architecture Overview

1. Curvance Lending Protocol

Curvance's market is designed around risk management, liquidity efficiency, and economic security, setting risk parameters for different asset classes through a "thesis-driven markets" architecture, such as stablecoins, blue-chip long exposures, and volatile LP assets. Each asset class operates under an independent Market Manager, isolating risk—fluctuations in one market do not infect the entire protocol, significantly reducing systemic risk.

The protocol adopts a unified cToken model: users deposit assets to earn interest-bearing cTokens, which can be used as collateral or for borrowing; the exchange rate increases with accumulated interest.

The Market Manager is responsible for managing the entire market's risk parameters, collateral and lending processes, liquidation logic, position health, and interest rate models.

Asset management controls exposure through a dual mechanism of collateral caps and debt caps, ensuring that even when utilization exceeds new caps, forced liquidations do not occur, but additional risks can be prevented.

Curvance's Dynamic Liquidation Engine (DLE) implements tiered liquidation (soft liquidation, hard liquidation, bad debt handling) and captures MEV through OEV liquidation auctions, enhancing speed, reducing costs, and minimizing on-chain burdens through off-chain bidding, batch processing, and efficient bidding algorithms, making the liquidation process efficient and fair.

The entire architecture constructs a lending protocol that maintains robustness and capital efficiency in a multi-asset environment through asset-specific risk parameters, a three-tiered liquidation mechanism, volatility-sensitive liquidation, and socialized bad debt.

2. Curvance Position Management

Curvance's position management system is a key component of the lending protocol, supporting users in advanced leverage and deleverage operations while maintaining protocol security in a multi-asset environment. This system allows users to manage complex DeFi positions in a structured manner while ensuring controlled risk.

Architecture Design

Position management consists of a generic base layer + multiple specialized implementations:

1. PositionManagementBase (Base Contract)

This is the abstract base class for all position management modules, providing core logic, including:

• General state variables and constants

• Core logic for leverage / deleverage

• Safety checks and fee calculations

• Market status queries and position calculations

• Standard interaction interfaces with other protocol modules

It forms the underlying framework for all position management strategies.

2. Specialized Implementations

On top of the base class, Curvance provides specialized position management modules for different asset types to accommodate their unique behaviors:

• PositionManagementSimple
  Suitable for standard tokens, handling simple exchange logic.

• PositionManagementPendlePT
  For the unique yield mechanism of Pendle PT (principal tokens).

• PositionManagementPendleLP
  Manages positions of Pendle LP (liquidity tokens).

• PositionManagementVelodrome
  Supports specific operations of Velodrome AMM.

• PositionManagementAerodrome
  An extended version of Velodrome, adapted for the Aerodrome protocol.

3. Curvance Dynamic Liquidation Engine (DLE)

Curvance's Dynamic Liquidation Engine (DLE) is a high-performance liquidation system designed for complex, multi-asset lending markets, achieving high-speed, secure, and capital-efficient liquidation processes through Atlas MEV integration, auction bidding, buffering mechanisms, dual oracle architecture, and batch processing logic.

1. MEV Auction Liquidation
   Rapid off-chain bidding occurs when liquidation is triggered, with the winner executing atomically in the same block, and profits flowing back to the protocol.

2. Auction Buffer
   A slight discount is applied to collateral, allowing auction liquidation to be prioritized and compensating for delays and non-oracle price fluctuations.

3. Transient Liquidation Parameters
   Liquidation incentives and close factors are instantaneously set within transactions and automatically restored, ensuring safety and control.

4. Efficient Batch Processing
   Supports multiple liquidations in a single transaction, unifying price caching and debt recovery, significantly reducing gas costs and delays.

5. Dynamic Liquidation Factor (lFactor)
   Continuous risk scoring determines the intensity of liquidation, with higher incentives and liquidation ratios as it approaches danger zones.

6. Dual Oracle Security Architecture

Two price sources cross-verify, with borrowers selecting high prices and collateral selecting low prices, resisting manipulation and extreme market conditions.

7. Strict Verification Process
   Checks liquidation parameters, permissions, and collateral unlocking status to ensure correct execution of auction and liquidation logic.

8. Protocol-Level Value Enhancement
   Captures MEV as protocol revenue while maintaining fast, secure, and low-cost liquidation capabilities under high volatility.

4. Curvance Plugin and Delegation System

Curvance's plugin and delegation system allows authorized third-party contracts or addresses to perform operations on behalf of users, supporting automated strategies, complex transactions, and cross-chain operations, but also introduces asset management risks.

The system consists of ActionRegistry, PluginDelegable, and Central Registry, managing users' transfer/delegation permissions, cooldown periods, and security statuses. Users' permission configurations are controlled by a state machine, including transfer locks, delegation locks, and a "master revocation mechanism" based on approvalIndex—once users increase approvalIndex, all old delegations become immediately invalid.

The system enforces a mandatory cooldown period to prevent attackers from inducing users to quickly unlock authorizations. The delegation relationship adopts a multidimensional mapping structure to accurately track the permission relationship of "user → approvalIndex → delegate." All plugin contracts must inherit PluginDelegable and enforce permission checks to ensure the legality of delegation operations.

This architecture enhances automation capabilities and capital efficiency while requiring users to authorize cautiously, as delegates can alter position risks, transfer assets, trigger leverage adjustments, or affect redemption processes.

Tron Comments

The advantage of Curvance lies in its innovative architecture centered on risk isolation, capital efficiency, and liquidation performance: it isolates risks of different asset classes through thesis-driven market design; the unified cToken model and dual cap mechanism (Collateral/Debt Caps) ensure flexible and controllable exposure; the Dynamic Liquidation Engine (DLE) combined with MEV auctions, batching, and dual oracle systems makes liquidation faster, safer, and cheaper, providing strong systemic protection for high leverage and complex asset portfolios.

Its disadvantages include: the overall architecture is relatively complex, posing a high understanding threshold for users and integrators; reliance on external components such as oracles, MEV systems, and off-chain bidding mechanisms necessitates verification of its robustness in extreme situations; and modules like advanced position management and delegation systems may introduce operational risks if configured improperly.

1.2. Interpretation of Total Financing of $8 Million ------ A New Generation Stablecoin Protocol Solomon That Requires No Collateral, No Lock-up, and Automatically Earns Yield

Introduction

Solomon is building a more composable dollar. A dollar that always maintains $1, does not rebase, and can generate yield.

Throughout the DeFi ecosystem, stablecoins used in exchange protocols to perpetual contract protocols generally do not generate yield. Solomon changes this, allowing billions of dollars of idle capital to become more efficient and productive.

Technical Framework Overview

1. USDv and sUSDv

Solomon includes two tokens:

• USDv

• Staked USDv (sUSDv)

USDv is a stablecoin that maintains a $1 peg through a two-way arbitrage mechanism. Users can obtain USDv through stablecoin liquidity pools, and it can also be minted or burned by approved entities.

Users can stake USDv to earn sUSDv. Yields are periodically distributed to the staking contract, smoothing the reward distribution process and avoiding arbitrage or front-running behavior.

The initial exchange ratio of USDv to sUSDv is 1:1. As yields are continuously distributed, this value accumulates in sUSDv, gradually skewing the exchange ratio towards sUSDv:

• When staking:
  The amount of sUSDv you receive will be less than the amount of USDv staked (because sUSDv is worth more)
  ------ but your total value remains unchanged.

• When redeeming:
  You will exchange sUSDv for more USDv because the yields have accumulated in sUSDv during the period.

2. Yield as a Service (YaaS)

YaaS will stream Solomon's yields directly to wallets holding USDv ------ no staking, no lock-up, no wrapped tokens required.

It is designed for teams, DAOs, LPs, and fintech partners that need "always available dollars + backend automatic yield."

Applicable Targets

• DAOs & Treasuries: Automatically generate yield on idle dollars without changing treasury operations.

• DEX LPs: Add extra yield (trading fees + base yield) on the USDv side of DEX pools.

• Fintech / Neobanks: Provide "default yield-bearing" dollar balances within applications.

• Market Makers / Integrators: Use USDv as operational funds while automatically earning streaming yields.

3. Yield Engine

Solomon's yield comes from funding rates and plans to incorporate T-bill yields for basis trading.

Basis Trading

Solomon builds basis trading portfolios using centralized exchanges (like Binance):

• Spot long

• Perpetual contract short

By establishing a market-neutral long-short structure on major assets (like BTC, SOL, ETH), Solomon captures:

• Perpetual contract funding rates

• Futures/spot basis yield

An automatic compounding mechanism ensures that yields are continuously and efficiently reinvested.

The resulting yields will be distributed to:

• sUSDv stakers

• Permitted USDv holders (YaaS)

Yield Flow

1. Authorized users mint USDv:
   Send equivalent assets to receive minted USDv.

2. Assets are used by custodial partners:
   To build basis trading positions.

3. Yields are periodically distributed:
   Allocated to the staking contract (sUSDv) and YaaS streaming yield users.

Tron Comments

The advantage of Solomon is that it proposes a stablecoin model that always maintains $1, does not rebase, and automatically generates yield, making USDv a composable "yield-bearing dollar," while achieving a flexible yield distribution mechanism through sUSDv and YaaS, unlocking the productivity of massive idle capital for DAOs, LPs, market makers, and fintech scenarios; its basis strategy (spot long + perpetual short) and automatic compounding structure make yield sources transparent, sustainable, and user-friendly with strong integration capabilities, no need for lock-up, and no additional operations.

However, Solomon's disadvantage is that yield relies on centralized exchanges and basis trading, posing strategic risks and trust assumptions on custodians; the mechanisms of USDv and sUSDv require user understanding, which may incur educational costs; at the same time, minting permissions and compliance requirements (KYC/AML) raise the entry threshold, making it not as permissionless as fully decentralized stablecoins. Overall, Solomon has significant advantages in "stability + yield + composability," but still has structural limitations in terms of trustlessness and strategy dependence.

2. Key Projects of the Week

2.1. Detailed Explanation of Total Financing of $25.3 Million, with Participation from Well-known Protocols like Curve and Aave --- The Native Bridge BOB Connecting Bitcoin Security and Ethereum DeFi

Introduction

BOB combines the security of Bitcoin with the innovations of Ethereum DeFi, becoming the best place to build applications and earn BTC yields.

• For users:
  One-click staking of Bitcoin, cross-chain BTC exchange, seamless access to DeFi.

• For developers:
  "Integrate BOB EVM to natively access BTC."

• Core Innovation:
  "BTC on BOB is BTC" ------ the world's first chain that simultaneously achieves finality from both Ethereum and Bitcoin.

Architecture Overview

1. Gateway (Onramp & Offramp) Mechanism Analysis

How Gateway (Onramp) Works

• Liquidity providers (LPs) temporarily lock Wrapped Bitcoin (WBTC or tBTC) in a custodial contract on the BOB chain.

• Users send requests to off-chain relayers to reserve available liquidity.

• Users send BTC to the LP's Bitcoin address. The hash of the user's order is written into the OP_RETURN field of their Bitcoin transaction, containing the user's EVM address on BOB and the strategy they wish to execute (intent).

• The relayer submits the Merkle proof of the user's Bitcoin transaction to the on-chain Bitcoin light client, which verifies and grants the relayer permission to withdraw the LP's wrapped BTC from the custodial contract.

• The Gateway transfers the LP's wrapped BTC to the user's EVM address; if the user requests BTC LST/LRT, it will first mint that token using the LP's wrapped BTC before sending it to the user.

Gateway (Onramp) Architecture and User Flow

User Flow

1. The user requests to exchange BTC for wrapped BTC (such as WBTC, tBTC, FBTC) or stake BTC (such as xSolvBTC, uniBTC).

2. The user receives a quote indicating available routes (i.e., matching LPs).

3. The user creates an order with the relayer, locking in the liquidity of that LP.

4. The user creates a Bitcoin transaction and updates the txid in the order. The Gateway SDK writes the hash of the user's intent into the transaction's OP_RETURN, including:

• The user's EVM address

• The strategy used (intent)

• The number of sats to convert to ETH for gas

• Other necessary metadata
  Writing a deterministic hash lays the foundation for future decentralization of relayers.

1. The relayer monitors the Bitcoin chain, and upon detecting the user's transaction, submits the Merkle proof of that transaction to the on-chain Light Client. Once verified, the LP's wrapped BTC is sent to the user.

Liquidity Provider (LP) Flow

1. The LP requests the relayer to deploy the Gateway contract (as custodial), currently permissioned, as gas is paid by BOB.

2. The LP deposits wrapped Bitcoin (WBTC, tBTC, FBTC) into the Gateway contract.

3. The LP can only withdraw funds or update swap fees after a delay period, allowing the relayer to complete all outstanding orders. During the delay, the relayer will not accept new orders.

How Gateway (Offramp) Works

• LP provides Bitcoin funding to the "solver" off-chain and registers the solver.

• Users request to exchange wrapped BTC for native BTC.

• Users submit off-ramp orders to OfframpRegistry, locking wrapped BTC and specifying their Bitcoin address.

• The solver listens for unfulfilled orders, accepts the order, and sends a Bitcoin transaction to the user while writing order ID and other metadata in OP_RETURN.

• The solver notifies the relayer, who submits the transaction to the on-chain OfframpRegistry via Merkle proof. Once the proof is successfully verified, the Wrapped BTC is unlocked and transferred to the solver.

• If the order is not processed in a timely manner, users can increase the transaction fee to incentivize the LP or unlock the assets after waiting.

Gateway (Offramp) User Flow

1. Users request to exchange wrapped BTC for BTC.

2. Users receive a quote (docking fee + liquidity situation).

3. Users lock their wrapped BTC in OfframpRegistry.

4. The solver accepts the order and sends a transaction to the user's Bitcoin address, including metadata in OP_RETURN.

5. If the order remains unfulfilled for a long time, users can increase the transaction fee or directly unlock the assets.

Gateway (Offramp) LP Flow

1. LP registers the solver address in OfframpRegistry.

2. LP runs the solver program and injects Bitcoin funding.

3. The solver listens for user orders and matches orders based on fee rate thresholds.

4. When accepting an order, the solver broadcasts a BTC transaction to the user address and writes metadata.

5. After the transaction is confirmed, the solver notifies the relayer; the relayer submits the transaction proof, unlocking wrapped BTC and transferring it to the solver as settlement.

2. BitVM: A New Paradigm for Bitcoin

BitVM plays a key role in BOB's Hybrid Chain roadmap, enabling BOB's Rollup to achieve a more advanced and secure Bitcoin cross-chain bridge. BOB will integrate a native Bitcoin bridge through BitVM, which will become the core infrastructure of the Bitcoin DeFi ecosystem and create synergies with Babylon's LST and LRT.

From network infrastructure to underlying assets, BitVM unlocks significantly enhanced security capabilities for Bitcoin DeFi.

Technical Details

A program is first compressed into a Groth16 SNARK verifier, which can be executed in Bitcoin Script but is about 1GB in size, so it needs to be split into many small verification subprograms (each less than 400kb) to run within Bitcoin's transaction size limits without any miner cooperation.

Participating operators need to stake collateral and continuously run the complete original program off-chain (e.g., cross-chain bridge logic), calculating the correct output corresponding to each input (such as how much BTC each user should withdraw). They will first cover these outputs with their own BTC and then apply to BitVM for reimbursement from the system funds.

If someone questions an operator's honesty, the operator must disclose all intermediate calculation results (inputs and outputs of each subprogram). As long as any step is forged, anyone can execute the corresponding subprogram on the Bitcoin chain to verify its incorrect results.

Once proven to be cheating, the operator will be removed and will not be able to recover the funds managed by BitVM.

3. BOB Chain Mechanism Analysis

a. Hybrid Stack

BOB's hybrid stack combines the security of Bitcoin, the programmability of Ethereum, and ZK cryptographic security through a layered architecture, building an ecosystem for seamless interaction between Bitcoin and Ethereum.

• Account and Wallet Layer: Supports EVM wallets like MetaMask and Rabby, as well as Bitcoin wallets like Xverse, Unisat, and Phantom; supports ERC-4337 and EIP-7702, as well as social login.

• BOB SDK: Shields developers from cross-chain complexity, allowing applications to directly receive BTC, perform single transaction deposits and withdrawals, and integrate with any DeFi protocol.

• DeFi Ecosystem: Integrates applications like Uniswap v3, Avalon, Euler, Solv, Lombard, and Bedrock, building an ecosystem around BTC yield, trading, and lending.

• Interoperability Layer: BOB Gateway serves as a fast programmable BTC bridge and connects multiple chains through third-party bridges.

• Hybrid Chain (Core of the Chain): Natively bridges Ethereum (OP Stack) and Bitcoin (BitVM), ensuring that "BTC on BOB is BTC"; provides complete EVM, ZK Rollup consensus, and dual-layer data availability (ETH main, BTC backup), supporting unilateral exits and providing on-chain validity proof level security.

b. Hybrid Chain

BOB is a new type of Hybrid ZK Rollup that inherits Bitcoin Finality and Ethereum security, achieving minimal trust interoperability with Bitcoin and Ethereum through native bridges. It combines Bitcoin's security, Ethereum's programmability, and ZK cryptography within a multi-layer architecture, allowing BTC to be seamlessly used in any application on any chain.

The core of BOB includes:

1. Native Bridges

• BitVM BTC Bridge: 1-of-n security model, a bidirectional Bitcoin bridge without soft forks, ensuring that "BTC on BOB is BTC"; supports unilateral exits and ZK-verified fraud proofs.

• Ethereum OP Stack Bridge: Fully inherits Ethereum security, supports native 1-click deposits and withdrawals for ETH, ERC20, and NFTs, with forced withdrawal capabilities.

1. Hybrid ZK Rollup Consensus

• BOB combines Optimistic Rollup and ZK Validity Proof:

• Default low-cost optimistic mode (4 days finality)

• Optional instant finality ZK mode (SNARK submitted on demand)

• Kailua allows disputes to verify only one mini-proposal, keeping proof costs low ($3, 0.5 ETH deposit, 250,000 gas).

1. Bitcoin Finality (Under Development)

• With the help of Babylon's BTC-Staked Finality Providers, Bitcoin stakers sign BOB blocks and bear the risk of slashing, providing Bitcoin-level economic security.

• Fast finality is provided by Bitcoin stakers, while long-term resistance to reorganization is provided by Bitcoin PoW.

1. Hybrid Data Availability

• Main DA: Ethereum's EIP-4844 blobs

• Backup DA: Bitcoin's strong censorship-resistant channel, enabling "forced exit to BTC"

c. Hybrid Nodes

Hybrid Nodes are the technical infrastructure providers running key services on the BOB chain. All nodes running core components on BOB are called hybrid nodes, responsible for:

• BitVM operation

• Bitcoin Finality

• Key services such as cross-chain bridges and data availability

Since the number of BitVM operators cannot expand indefinitely (each additional operator brings extra off-chain data overhead), BOB employs a BOB token delegation mechanism to select and rank nodes. Nodes that receive more BOB delegation and demonstrate reliability will be prioritized as key infrastructure operators.

Current main roles include:

1. BitVM Operators (Native BTC Security Operators)

• BitVM uses a "1-of-n" security model: as long as there is one honest online node, native BTC on BOB is secure.

• BitVM operators are responsible for maintaining all BitVM-related security processes, including triggering fraud proofs.

• Node ranking is determined by their reliability and the amount of BOB token delegation.

1. Finality Providers (Bitcoin Finality Providers)

• Provide Bitcoin-level soft-finality for BOB blocks through Babylon's Bitcoin Staking Network (BSN) or BOB's OptiMine merged mining protocol.

• The selection of FPs is also based on community contributions and BOB token delegation.

Tron Comments

The advantage of BOB lies in its unique Hybrid Chain architecture: inheriting the finality of Bitcoin and the programmability of Ethereum, creating a minimal trust native BTC bridge through BitVM, ensuring that "BTC on BOB is BTC," and combining OP Stack, ZK proofs, and a hybrid DA model to achieve higher security, scalability, and cross-chain flexibility; developers can directly use BTC in an EVM manner, and users can enjoy a fast, low-cost, and forcibly exit experience.

However, its disadvantages include: a highly complex architecture that relies on multiple layers of components (BitVM, Kailua, OP Stack, Babylon) working together; some key mechanisms are still under development (BTC Finality, Bitcoin DA, BitVM mainnet); cross-chain bridges and hybrid consensus may face implementation difficulties, performance bottlenecks, or user education costs in the early stages. Overall, BOB has a significant leading advantage in "BTC security + EVM programmability + minimal trust cross-chain," but the maturity of technology and the completeness of the ecosystem still need to be gradually improved as the stages progress.

1. Overall Market Performance

1.1. Spot BTC vs ETH Price Trends

BTC

ETH

2. Summary of Hot Sectors

Macroeconomic Data Review and Key Data Release Points for Next Week

Last week, several Federal Reserve officials repeatedly emphasized in year-end speeches that "interest rates are in a restrictive range, and the next step depends on data," acknowledging the trend of falling inflation and cooling employment, but remaining restrained against premature and rapid interest rate cuts, with an overall tone of "the turning point has arrived, and the pace is cautious." At the same time, Treasury officials mentioned that the issuance pace and maturity structure of government bonds at the beginning of the year will focus more on market capacity, interpreted as a gentle support for long-term yields.

Important data to be released this week:

December 31: Initial jobless claims in the U.S. for the week ending December 27.

Regulatory Policies

Portugal

Portugal completed the domestic legislation of two key EU crypto regulations this week, ending the policy uncertainty since 2024.

• Comprehensive implementation of the EU Crypto Assets Regulation: On December 22, two laws were published regarding the implementation of the Markets in Crypto-Assets Regulation (MiCAR) and the Transfer of Funds Regulation (TFR).

• Establishment of a "dual-peak" regulatory model: The law clarifies the joint regulatory responsibilities of the Bank of Portugal (BdP) and the Portuguese Securities Market Commission (CMVM), forming a unique regulatory framework.

• Bank of Portugal: Mainly responsible for the regulation of stablecoin (asset-referenced tokens and electronic money tokens) issuance, as well as overseeing the authorization, prudential requirements, and corporate governance of crypto asset service providers.

• Securities Market Commission: Mainly responsible for regulating the issuance of other crypto assets excluding stablecoins, market abuse behaviors, and the commercial obligations of crypto asset service providers to their clients.

• Establishment of a transition period: Virtual asset service providers registered with the Bank of Portugal can continue to operate until July 1, 2026, by which time they must obtain full MiCAR authorization.

European Union

The EU Council recognizes the digital euro plan: On December 23, the EU Council officially recognized the digital euro plan proposed by the European Central Bank (ECB). This plan will include an offline version that emphasizes privacy protection.