I. Outlook

1. Summary of Macroeconomic Trends and Future Predictions

This week (March 23 - March 28), the macroeconomic focus is on three points: "high inflation pressure + policy wait-and-see + geopolitical and trade disturbances": The Federal Reserve maintained interest rates and raised inflation expectations, clearly indicating that the short-term rate cut space is narrowing, leading the market to reprice the path of "maintaining high interest rates for a longer time"; at the same time, the situation in the Middle East and fluctuations in energy prices are increasing inflation uncertainty, while the Trump administration's push for a new round of tariff policies has raised expectations, making the risk of "imported inflation + economic slowdown" stagflation heat up again. Overall, the global macro environment remains in a transitional phase of tight monetary policy and intertwined uncertain shocks, with increased volatility in risk assets but not yet entering a trend reversal.

In the coming week, the market's core will revolve around repricing inflation paths and policy expectations: In the short term, the Federal Reserve is likely to continue to wait and see, maintaining high interest rates, and the market will be more sensitive to oil prices, the pace of tariff implementation, and changes in employment data; if inflation data continues to be strong, risk assets may come under pressure, while marginal easing may trigger a short-term rebound. The overall judgment is: the macro environment remains "tight + uncertain," with asset prices primarily fluctuating, and directional choices still need to wait for clearer inflation or policy signals.

2. Market Changes and Warnings in the Cryptocurrency Industry

This week (March 23 - March 28), the cryptocurrency market is largely dominated by macro policies and regulatory expectations, with significant increases in volatility: On one hand, the Trump administration's push for a new round of tariffs and economic policy expectations has caused cryptocurrency assets to continue to exhibit "risk asset attributes," making the market highly sensitive to trade frictions; on the other hand, the increasing divergence in U.S. regulation of stablecoins (such as restrictions on interest earnings and the promotion of regulatory frameworks) has put significant pressure on related assets and concept stocks, while also reinforcing the narrative that "stablecoins = national financial competition tools." Overall, the market has entered a phase dominated by macro drivers and policy games, with a cautious risk appetite for funds.

Key warnings for next week: First, the further implementation of tariff policies or the announcement of details may continue to amplify market volatility (historically, similar policies have triggered significant volatility and liquidations); second, the progress of stablecoin regulation and legislative games will directly affect the flow of funds and DeFi/payment narratives; third, policies and geopolitical events (such as the situation in the Middle East and abnormal funds in prediction markets) may trigger short-term emotional shocks.

3. Industry and Sector Hotspots

This week, the primary market continues to focus on on-chain transactions and liquidity infrastructure upgrades: Derive completed a $6.8 million financing (led by GSR, LayerZero, and Framework), focusing on a self-custodial trading architecture based on proprietary Rollup; Euclid received $3.5 million in support (with participation from KuCoin, Gate, and OG Labs), aiming to build a decentralized liquidity consensus layer for the entire chain; while Flying Tulip entered higher-level on-chain risk and liquidity management with a large financing of $255 million (led by Amber and DWF), creating a risk engine centered on "executable liquidity."

II. Market Hotspots and Potential Projects of the Week

1. Overview of Potential Projects

1.1. Brief Analysis of Total Financing of $6.8 Million, Led by GSR, LayerZero, and Framework - A Self-Custodial Trading Infrastructure Driven by Proprietary Rollup: Derive

Introduction

Derive is a self-custodial, high-performance cryptocurrency trading platform that supports options, perpetual contracts, and spot trading. The platform consists of three parts: Derive Chain, as the trading settlement layer, is built on the OP Stack and secured by the Ethereum mainnet as an Optimistic Rollup, governed by Derive DAO; Derive Protocol is deployed on Derive Chain, providing a permissionless, user self-custodial margin trading settlement protocol, also governed by Derive DAO; Derive Exchange is responsible for efficient matching and settles transaction results to Derive Protocol, operated by Derive Trading Co.

Core Mechanism Overview

Derive Protocol

Derive Protocol is a collection of smart contracts that together build a decentralized, user self-custodial derivatives protocol.

The protocol mainly consists of three core components:

• Accounts: ERC-721 asset accounts held by users, used to store their assets (including cash, derivatives, and underlying assets). All accounts must subscribe to a manager.

• Risk Managers: Responsible for managing the margin requirements of subscribed accounts. When an account falls below the specified margin level, the manager is responsible for liquidating that account.

• Assets: Contracts used to define the attributes and rules of various assets and derivatives (such as options and perpetual contracts).

In addition, the protocol has a Security Module for storing reserve funds. In the event of trader bankruptcy leading to bad debts, this module will be used to repay uncovered debts. As a return for providing a safety net for the system, the protocol charges fees to traders through the manager, which are used to continuously expand the scale of the security module.

All margin calculations are executed on-chain in a trustless manner, with relevant calculation parameters set by the governance mechanism.

1) Positioning and Responsibilities: Derive's "Settlement Layer"

The core role of Derive Chain is to execute and settle transactions and clearing results generated by Derive Exchange/Protocol in a low-cost, high-throughput manner on L2, while anchoring security to the Ethereum mainnet (the trust root of Optimistic Rollup is on L1). Derive officially defines it as a settlement layer based on OP Stack, secured by the Ethereum mainnet, and governed by Derive DAO.

2) Key Links of OP Stack Rollup: Sequencer → Batcher/DA → Derivation

Derive Chain inherits the typical pipeline of OP Stack:

• Sequencer (Ordering/Block Production): Responsible for receiving user transactions, ordering them, and quickly providing L2 block confirmations (the experience of "very fast confirmation" often comes from here).

• Batcher + Data Availability: Packages L2 transaction data and submits it to Ethereum L1 (as calldata or blobs), ensuring that anyone can reconstruct L2 from L1 data. Ethereum's description of Optimistic Rollup is that L2 execution is completed off-chain/on-chain, but data is published to the mainnet for security and verifiability.

• Derivation Pipeline: OP Stack nodes "derive" consistent L2 blocks and states from the data published on L1; this is the core responsibility of Rollup nodes in validator and sequencer modes, ensuring that L2 states are replayable, verifiable, and can handle situations like L1 reorganization.

Intuitively: Derive Chain's "authoritative truth" ultimately comes from available data on L1 + determined derivation rules, rather than just the sequencer's "say-so."

3) Security Model: The "Challenge/Error Correction" Approach of Optimistic Rollup

As an Optimistic Rollup, Derive Chain defaults to "optimistically" accepting L2 execution results, but its security comes from:

• L2 transaction data being available on L1;

• The protocol design and proof/challenge mechanisms of OP Stack (specific implementations vary with OP Stack/chain configurations), allowing erroneous states to be identified and corrected in principle;

• Therefore, Derive Chain's ultimate security is anchored to the Ethereum mainnet.

(On the product side, this means: fast confirmation ≠ final certainty; withdrawals/cross-domain messages usually require waiting for the corresponding finality window and protocol processes.)

4) System Contracts and Cross-Domain Communication: Enabling L2 and L1 to "Talk to Each Other"

OP Stack chains typically contain a set of system contracts/bridge contracts within L2, used to handle messages, deposits and withdrawals, and fee aggregation between L1 and L2, with some being automatically updated during the derivation process (e.g., system information related to L1 states).
For Derive Chain, this set of system contracts is the key infrastructure that allows it to "use Ethereum as a security anchor and L2 for high-performance settlement."

5) Fees and Economics: Transaction Fees, L1 Data Costs, and Fee Aggregation

Under the OP Stack model, user transaction fees on L2 typically consist of two parts:

• L2 execution costs (computational/storage consumption on L2)

• L1 data publishing costs (the cost of publishing transaction data to Ethereum, which the rollup must pay)

Additionally, the OP Stack system generally has different fee vaults/aggregation contract designs to handle fee flows (e.g., base fees, sequencer fees, etc.).
For Derive Chain, this fee model directly determines whether high-frequency trading/clearing on-chain is "economically feasible."

6) Governance and Upgrades: The Control Aspect of Derive DAO

Derive officially states: Derive Chain is governed by Derive DAO.
In the OP Stack architecture, governance typically affects:

• Chain parameters (gas, fee models, block times, etc.)

• The upgrade pace of system contracts and bridges

• Security-related configurations (e.g., the route of challenge/proof systems, the advancement of decentralized sequencers, etc.)

Derive DAO

1) Governance Objects and Boundaries of the DAO

Derive DAO is positioned to design, build, and govern the Derive derivatives ecosystem (chain, protocol, governance framework, and funds). Its structure consists of five parts: governance system, tokens, protocols, vaults, and service providers.

2) Source of Governance Power: DRV → stDRV (Governance Rights Obtained After Staking)

• DRV is the base token for governance and incentives; staking DRV to obtain stDRV is required to participate in governance.

• stDRV grants two types of powers:

1. Proposal Right: The right to initiate proposals.

2. Voting right: Participation in voting and supporting delegation allows part or all of the proposal rights/voting rights to be delegated to more professional members, retaining the efficiency advantages of "committee-style" governance.

• stDRV has governance security design: non-transferable, 28-day unlocking period, and also supports "20% penalty for immediate unlocking."

3) Proposal System: LEAP (Standard proposals affecting protocols/treasuries/governance)

Derive unifies proposals affecting protocols, treasuries, or governance frameworks into LEAP (an industry-standard format similar to EIP/BIP).
Each LEAP must include: summary, motivation, specifications, design rationale, test cases (code-related), copyright waiver, and other standardized elements to ensure proposals are reviewable, executable, and accountable.

4) Governance Process: Forum LRFC → Snapshot (optional/some scenarios are binding) → On-chain voting → Automatic execution

Derive's governance process is divided into:

1. LRFC (Forum Draft) discussion and consensus formation

2. Snapshot: Used for quick, low-cost public opinion testing; can serve as the final and binding vote for matters that do not require on-chain contract calls (e.g., adjustments to trading/liquidity reward formulas)

3. On-chain voting: Conducted by stDRV holders

4. Execution: Automatically executed through timelock for approved proposals

5) Execution and Security: Governance contract + Strategy contract + Dual Timelock + Cross-chain executor

Derive uses a set of on-chain governance contract systems for "proposal creation---voting---meeting standards---queuing---execution."
Key security and execution components include:

• Governance Strategy: Calculation of proposal rights/voting rights (including delegation)

• Short / Long Timelock Executor: Differentiates execution delays and authority boundaries for different categories of proposals (short timelock can execute protocol changes and treasury proposals; long timelock handles stDRV and meta-governance proposals)

• Cross-chain executor: Supports orchestrating proposal execution to other networks (the document mentions Optimism/Arbitrum executor mechanisms)

• Guardian cancellation rights (early safety fuse): Before execution, the community multi-signature controlled guardian account can cancel proposals as an initial protective measure.

6) Treasury: The "funding and incentive hub" of the DAO

Derive Treasury is defined as the financial backbone of the ecosystem, with core functions including:

• Funding trading incentives, market-making/liquidity plans, and other ecological growth budgets

• Using part of the protocol and rollup fees for DRV buybacks (described in the document as a periodic buyback mechanism)

• Unused rewards flowing back to ensure long-term self-sustainability

• stDRV oversees fund allocation through on-chain governance

7) Service Providers: The "outsourced execution layer" of the DAO

Any individual/team can apply to become a service provider through LEAP, applying for a budget from the DAO and delivering work.
Proposals must clearly state: service content, funding needs, value type (direct/indirect), team background, milestones, reporting mechanisms; the approval process is community discussion → Snapshot → On-chain voting → Funding and delivery after approval.

8) "Chain-level governance touchpoints": Derive Chain contract deployment whitelist

Derive Chain has a Deployer Whitelist (integrated by the sequencer), and only addresses approved by the DAO can deploy contracts; applications require posting in the forum and initiating Snapshot voting, after which the infrastructure party will add the address to the whitelist.

Tron Commentary

Derive's core advantage lies in its adoption of a "dedicated Rollup (Derive Chain) + self-custody settlement protocol (Derive Protocol) + high-performance order book matching (Derive Exchange)" three-layer architecture, combining centralized exchange-level matching efficiency with DeFi's self-custody and verifiable settlement, while enhancing the systemic resilience of derivatives trading under extreme market conditions through on-chain margin calculations, risk manager liquidation mechanisms, and security modules.

Its main disadvantage is the high complexity of the architecture and system coupling, with a stronger reliance on sequencers, order book operators, and risk parameter governance, and the derivatives market is highly sensitive to liquidity and market-making depth, which may still face challenges in experience and stability during cold starts or periods of extreme market volatility.

1.2. Interpretation of total financing of $3.5 million, with investments from Kucoin, Gate, and OG Labs ------ a decentralized liquidity consensus layer for the entire chain, Euclid

Introduction

Euclid is an open-source, decentralized liquidity consensus layer designed to allow any application to access a shared liquidity framework. By building a consensus-driven underlying network to connect different blockchains, Euclid facilitates the formation of a collaborative ecosystem, enabling participants to gain deeper liquidity, faster settlement speeds, and a more seamless trading experience.

Additionally, Euclid's modular architecture allows dApps to call large-scale liquidity from any integrated chain and easily interact with cross-chain tokens within the entire ecosystem.

Architecture Analysis

1. Integrated Chains Layer

Factory Contract

The Factory smart contract is the core component of Euclid on each integrated chain, used to manage user interactions with liquidity pools and execute swaps.
Its main responsibilities include: receiving user requests and forwarding them to the Router contract. The Factory simplifies user operations by providing a unified entry point, including:

• Swap

• Add liquidity

• Remove liquidity

Each chain connected to Euclid will have a Factory contract deployed by Euclid.

Single Entry Point

The Factory contract is the only communication point between the chain and VSL (Liquidity Consensus/Settlement Layer), and this design brings three key benefits:

1) More consistent and sequential request handling

All requests from the same chain are handled uniformly by the Factory, avoiding conflicts and inconsistencies caused by multiple entry points, and ensuring operations are executed in the correct order.

2) Stronger security

All cross-layer messages must go through the Factory, making it easier for the system to implement unified security checks to ensure request legitimacy.

3) Simpler developer experience

Protocols integrating Euclid only need to interact with one contract (Factory), significantly reducing integration complexity.

Workflow (using Swap as an example)

The execution path of a swap request is as follows:

1. The user sends a swap request to the Factory

2. The Factory forwards the message to the Router through a dedicated channel

3. The Router forwards the message to the VSL, where the swap calculation is completed

4. The VSL returns confirmation (acknowledgement) to the Router

5. The Router returns the ack to the Factory through a dedicated channel

6. The Factory forwards the ack to Escrow, which releases tokens to the user

7. Escrow Contract

The Escrow smart contract is an extremely simple structure used to hold a single type of token.
Each chain connected to Euclid will deploy a corresponding Escrow to hold the token liquidity on that chain.

When a swap is successfully completed, the Factory contract on the chain will forward the message from the Router to the Escrow, requesting it to release the corresponding tokens to the user who initiated the swap.

Collaboration with Virtual Liquidity Pool (VSL)

The Escrow establishes a communication relationship with the Virtual Pool (VSL) through the Factory and Router, receiving messages and executing token transfers when conditions are met.

When a user swaps Token A for Token B, one of two scenarios occurs:

1. Transaction successful

• The Escrow holding Token A successfully manages A

• The Escrow holding B on another chain (or the same chain) releases Token B to the user

1. Transaction failed (high slippage or timeout)

• The Escrow returns the user's deposited Token A back to the user

Cross-chain Release Capability

Euclid allows users to specify at the time of transaction initiation:

• On which chains to release funds

• The specific amount to be released on each chain

Thus, the Escrow that ultimately releases tokens to the user can be located on any integrated chain, not necessarily the same as the chain where the user initiated the transaction.

Virtual Settlement Layer (VSL)

The VSL (Virtual Settlement Layer) consists of two core parts, jointly responsible for the calculation and accounting consistency of cross-chain swaps:

1. Virtual Liquidity Pools (VLP)

• VLP is responsible for all swap calculation logic for a specific token trading pair

• Including price calculation, exchange amounts, slippage judgment, etc.

• VLP does not directly hold real assets but models the entire network liquidity in the virtual layer

Can be understood as: the "mathematics and pricing engine" for cross-chain shared liquidity

2. Virtual Balances

• Virtual Balance is used to record all balance changes between users and VLP

• Ensures that asset changes in each swap are correctly accounted for

• Guarantees that assets are not lost, duplicated, or generated out of thin air under any circumstances

Can be understood as: the global ledger and consistency assurance layer of the Virtual Settlement Layer (VSL)

Tron Comments

The core advantage of Euclid lies in its ability to abstract multi-chain liquidity into a shareable unified framework through a "liquidity consensus layer + Virtual Settlement Layer (VSL)", achieving consistency, scalability, and a smoother developer integration experience for cross-chain swaps by utilizing a single entry point via Factory + Router routing + VLP unified pricing + Virtual Balances global accounting + Escrow for real assets on each chain, allowing users to release assets on any integrated chain, thereby enhancing settlement flexibility.

Its main disadvantage is the complexity of system components, long cross-chain message links, and strong reliance on communication reliability and security assumptions. Additionally, the global ledger and virtual pool mechanism of VSL require sufficient multi-chain and deep liquidity access to leverage scale advantages, which may face challenges such as cold starts, delays, and execution complexity under extreme market conditions in the early stages.

2. Key Project Details of the Week

2.1. Detailed Explanation of Total Financing of $255 Million, Led by Amber & DWF, with Participation from Well-Known Institutions like Coinfund and Selini — The On-Chain Risk Engine Flying Tulip Focused on Executable Liquidity

Introduction

Flying Tulip is an on-chain financial system designed to unify and standardize pricing, credit, and risk management around a complete set of products, covering spot trading (AMM and CLOB), lending, perpetual contracts, insurance, and settlement tracks for cross-product clearing. Its core settlement layer is ftUSD: a delta-neutral, yield-bearing stable asset targeting a peg of $1, which reduces liquidation risk by balancing long and short exposures (e.g., supply/staking/lending cycles).

The design goal of Flying Tulip is clear: to reuse the same collateral system across multiple functional modules; to use real executable on-chain liquidity as the primary source of pricing rather than static risk tables or lagging oracles; and to transparently and programmatically return cash flows generated by the system to the tokens, thereby forming a sustainable on-chain financial closed loop.

Core Element Analysis

1. ftUSD (Flying Tulip)

Product Overview

ftUSD is the dollar-pegged token of Flying Tulip, designed with a "stability first" goal and optional yield:

• Unstaked ftUSD: defaults to stable, non-yielding, can be used as a composable on-chain dollar within the ecosystem for trading, settlement, and collateral.

• sftUSD: the receipt token obtained by users after staking ftUSD, used to accumulate staking pool yields (yields are voluntarily chosen by users).

The yields generated by unstaked ftUSD will belong to the protocol to support operations and deepen liquidity; stakers will receive allocated yields. Both ftUSD and sftUSD are fully on-chain, auditable, and transparent system designs that do not rely on oracles or centralized components.

Why Choose ftUSD

• Stable pricing unit: targeting a peg of $1, serving as the settlement currency for the entire Flying Tulip product system.

• Optional yield: stake to earn sftUSD if you want yield; remain purely stable and instantly liquid if you do not stake.

• Resilient design: employs a delta-neutral architecture to reduce liquidation risk by balancing long and short exposures and maintaining conservative position sizes.

• On-chain transparency: collateral, parameters, and fund flows can all be verified on-chain.

• High composability: ftUSD can be used across various products in Flying Tulip (trading, settlement, collateral, liquidity provision, etc.).

How ftUSD Works (Core Mechanism)

ftUSD maintains its dollar peg through a set of balanced delta-neutral strategies:
The strategy combines conservative money market yields with staking yields while using hedged shorts to offset directional risk, keeping the overall net exposure close to 0, thus generating net yields (after costs) while controlling risk.

Example Strategy Flow (Illustrative)

One possible strategy path is as follows:

1. Deposit the underlying collateral asset into a money market (e.g., USDC → Aave) to earn low-risk interest.

2. Borrow a hedging asset against that collateral (e.g., Sonic's S) to form a short leg (you owe S).

3. Stake the borrowed asset (e.g., S → stS) to earn staking yields, forming a long leg.

4. Conduct prudent cycles (e.g., re-depositing stS into the money market) to increase safety margins and carry.

Longs (staking) and shorts (borrowing) will be paired proportionally to offset directional risks and reduce liquidation probabilities. The system constrains tail risks through risk controls (position limits, rebalancing ranges, venue restrictions, etc.).

2. Spot (Flying Tulip Spot)

Product Overview

Flying Tulip's Spot is the trading engine and price source for the entire ecosystem:
It is responsible for completing exchange transactions, carrying liquidity supply, and providing core signals for the system's pricing, funding rates, and risk management.

The design of Spot is not to fix a single AMM curve "betting the market will behave," but to allow AMM to adapt in real-time:

• In stable markets, the goal is to provide a low spread experience close to professional market makers;

• In times of increased market volatility, the curve will increase "curvature" to buffer shocks and protect liquidity providers.

Spot also provides:

• Adaptive AMM

• CLOB (Centralized Limit Order Book): supports limit orders

Trades can be fully executed on AMM, fully executed on CLOB, or a mixed routing of both — to obtain the optimal price executable under the current order size.

Trading Experience: Optimal Routing of AMM + CLOB

When you initiate an exchange, the router will simultaneously check both "ledgers":

• If there are better-priced limit orders on CLOB, those will be prioritized for execution.

• The remaining portion will then be executed according to the adaptive AMM curve.

Before the trade is finally executed, the router will simulate the transaction on-chain to check if it exceeds:

• Slippage tolerance

• Pool risk guardrails

If the impact of a single execution is too large, the order can be split and executed in block slices to pass through depth more gently.
Transaction fees will also dynamically adjust with market conditions:

• Lower during stable times to encourage trading flow

• Higher during turbulent times to compensate liquidity providers and suppress toxic trading

1. Lend (Flying Tulip Lend)

Product Overview

Lending in crypto is simple: you lend assets, others borrow, and interest connects supply and demand. Most protocols stop here.
Flying Tulip's FT Lend places the familiar lending model into an adaptive market that "understands" depth, volatility, and real executable prices — these contexts determine how much you can safely borrow, what the borrowing costs are, and how to unload positions when liquidation is needed.
The result is: an experience similar to what you are familiar with in lending, but behaviorally more like accessing a "living market."

Dual-Layer Lending Structure: Permissionless + Permissioned

FT Lend exists in two forms:

1) Permissionless Layer

• As long as there is a trading pair on Spot, a corresponding lending market will be automatically generated.

• For example, if there is an ETH/USDC pool on Spot, a lending pair ETH↔USDC will automatically appear without the need for governance whitelisting.

• The system will calculate "scale-aware borrowing capacity" based on Spot's depth: the feasibility and risk of small versus large borrowings will yield different lending spaces.

2) Permissioned Pool

• Covers a selected set of assets that the protocol is willing to broadly cross-collateralize and preset risk parameters.

• This is the backbone of the entire system's collateral: CLOB, Futures, settlement, and clearing logic are all aligned with it.

• Key capability: a single deposit can be used simultaneously for lending, limit order collateral, and futures margin, eliminating the need to move funds between different products, reducing "idle capital."

1. Futures (Flying Tulip Futures)

Product Overview

Perpetual contracts allow you to trade with leverage without an expiration date. Most platforms rely on external oracles for pricing: oracles update every few seconds, determining liquidation and safety states, which leads to two typical issues:

1. Delay: during volatile markets, users may be liquidated at "expired prices."

2. Expanded risk surface: errors in oracle integration, governance delays, or upstream failures can transmit to positions.

Flying Tulip Futures takes a completely different approach: it does not borrow prices from external sources but uses its own Spot trading as the price truth.
If ETH trades at $1800 on Spot, that is the settlement price for the perpetual contract. No need to wait for oracle ticks.
The direct result of this design is: quotes are more real-time, settlements are sub-second (<500ms), and liquidations are based on truly executable prices, significantly reducing oracle lag and manipulation risks.

Collateral and Leverage: Isolated or Cross-Collateralized

FT Futures supports two margin modes:

• Isolated Margin: provides collateral for a single market separately, isolating risk.

• Cross-Collateral: achieved through permissioned Lend pools, a single deposit can simultaneously support:

• Perpetual positions

• CLOB limit orders

• Lending positions

More importantly: in cross-collateral mode, your collateral assets can continue to accumulate money market yields while supporting trades, achieving higher capital efficiency.

Maximum leverage is not a fixed table but dynamically contracts or relaxes based on TWAR depth and volatility windows; snapshots of limits will be taken during openings or adjustments to avoid retrospective changes in rules during positions.

Funding rates: tied to real borrowing costs rather than external speculation.

The role of the funding rate is to pull the perpetual price back to the spot.
The funding rate of FT Futures is anchored to the real economic conditions within the system:

• Actual borrowing costs in the lending market

• The degree of long and short crowding reflected by Spot and Lend

When long positions are essentially "borrowing dollars to go long," and borrowing costs are higher, the funding rate will reflect this reality; when there is crowding in short positions, the funding rate may reverse.
Users can see the sources of the funding rate inputs, update cycles, and why they are paying/receiving the funding rate.

Who bears the counterparty risk: Optional Settlement LP

Perpetual contracts require a counterparty at settlement. FT solves this through an optional settlement pool:
LPs deposit ftUSD, voluntarily taking on settlement liquidity in exchange for a fee at each settlement (approximately 0.05% as per policy in the example).
The system balances exposure among LPs, who can adjust parameters or exit.

The significance of this design is:

• No one is forced to take on unwanted risks

• The launch of new markets relies more on "Spot liquidity + ftUSD settlement supply," rather than waiting for the oracle integration committee's schedule

1. Insurance (Flying Tulip Insurance)

Product Overview

Traditional crypto insurance is more like a subscription model: a one-time payment, fixed term, hoping nothing goes wrong. FT Insurance adopts a completely different design—treating insurance as a market-driven lending pool.

• Buyers do not "buy a policy for a period," but open an insurance position, paying premiums only as needed for protection

• Capital providers contribute capital to the pool, continuously earning premium income

• The scale of insurance can dynamically expand or contract on a minute-by-minute basis

The result is a protection system that "breathes with the market":
When returns are high, capital naturally flows in, and when demand arises, coverage capacity expands, aligning the costs paid by users with their actual risks.

Tron Commentary

The core advantage of Flying Tulip is that it does not piece together spot, lending, perpetual, and insurance separately, but uses Spot as the pricing hub for real executable liquidity, integrating Lend, Futures, and Insurance with the ftUSD settlement layer into the same "deeply perceived" risk and cash flow system: LTV, leverage, funding rates, and liquidation are dynamically adjusted based on on-chain transactions and reserve windows, reducing systemic errors caused by oracle lag and static risk control tables, and forming a sustainable closed loop through a token-first income return mechanism;

Its main disadvantage is that the architecture is highly complex and tightly coupled, with a high dependence on Spot liquidity and market depth. If early depth is insufficient or extreme market conditions occur, pricing, liquidation, and insurance adjudication may all come under pressure, and while cross-product collateralization improves capital efficiency, it also amplifies portfolio risk and complicates governance parameter settings.

III. Industry Data Analysis

1. Overall Market Performance

1.1. Spot BTC vs ETH Price Trends

BTC

ETH

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

This Week's Macroeconomic Review (March 23 - March 28)

PMI data release (Europe/US/Global): Reflects the health of the manufacturing and service sectors, serving as the core growth indicator for this week.

US Initial Jobless Claims: Marginal changes in the labor market remain a focus.

Michigan Consumer Confidence Index (Final Value): Confidence weakened under energy price shocks.

Global macro main lines:

• Middle East situation + oil price fluctuations → Boosting inflation expectations

• Market attention on Federal Reserve statements and policy paths

Key Data for Next Week (March 30 - April 3)

Key (High Impact):

• 🇺🇸 JOLTS Job Openings (3/31) → Labor demand

• 🇺🇸 ISM Manufacturing PMI (4/1) → Economic turning point

• 🇺🇸 Non-Farm Payroll Report (4/3) → The most core data

Secondary Key:

• 🇺🇸 Initial Jobless Claims (4/2) → High-frequency employment indicator

• 🇺🇸 Trade Balance (4/2) → External demand and dollar impact

• 🇺🇸 ISM Non-Manufacturing (4/3) → Strength of the service sector

V. Regulatory Policies

United States

1. Regulatory framework clearly shifts to "loose + legislative-led"

• SEC/CFTC introduces a new classification system for crypto assets (Token Taxonomy):

• Most crypto assets are classified as commodities, payment tools, etc., rather than securities

• Significantly reduces the SEC's regulatory scope

• Regulatory focus shifts from "enforcement actions" to "legislative norms," promoting:

• Stablecoin framework (GENIUS Act)

• Market structure legislation (Clarity Act)

Impact:
The US is entering a phase of "de-enforcement + clear legislative framework," which is favorable for institutional capital entry, but increases investor protection disputes.

2. Discrepancies remain in stablecoin regulation

• Discussions in Congress include:

• Limiting stablecoin yields (similar to bank deposit regulation)

• Raising compliance thresholds

Impact:
Stablecoins have become the regulatory focus this week, with directions not yet fully unified.

3. High-level policies strengthen crypto strategic positioning

• The White House establishes a higher-level technology advisory system (including crypto policy)

• Promoting:

• National-level crypto strategy

• Policies such as Bitcoin reserves

Trend Summary:
The US is incorporating crypto into the national strategic technology competition framework.

United Kingdom

1. Ban on crypto for political donations (significant regulatory action)

• The government announces:

• Prohibition on political parties accepting cryptocurrency donations

• Preventing foreign funding interference and anonymous fund inflows

Impact:
This is the first clear policy globally targeting "crypto + political financing."

2. Strengthening transparency regulation for crypto funds

• Temporary measures include:

• Strengthening scrutiny of fund sources

• Suspending or restricting use in high-risk scenarios

European Union

1. MiCA continues to advance detailed execution

• This week's focus is on:

• Refining stablecoin (ART/EMT) rules

• Strengthening requirements for reserves, disclosures, and redemption mechanisms

Impact:
The EU continues to promote the world's strictest and most systematic crypto regulatory framework.

Australia

1. Compliance licenses become the core of industry access

• Ripple obtains AFSL financial license

• Regulatory requirements:

• Large-scale trading institutions must operate with a license

• Full integration into the regulatory system by 2028

Trend Summary:
Australia is entering a "traditional financial licensing regulatory path."