交易所還是券商?Hyperliquid的商業模式抉擇

標題:Hyperliquid 在十字路口:Robinhood 還是 Nasdaq 經濟學

作者:@shaundadevens

編譯:Peggy,BlockBeats

編者按:當 Hyperliquid 的成交規模逼近傳統交易所,真正值得關注的已不只是「量有多大」,而是它選擇站在市場結構的哪一層。本文以傳統金融中「券商 vs 交易所」的分工為參照,分析 Hyperliquid 為何主動採用低費率的市場層定位,以及 Builder Codes、HIP-3 如何在放大生態的同時,對平台抽成形成長期壓力。

Hyperliquid 的路徑,折射的是整個加密交易基礎設施正在面對的核心問題:規模做大之後,利潤究竟該如何分配。

以下為原文:

Hyperliquid 正在處理接近納斯達克級別的永續合約成交量,但其盈利結構同樣呈現出「納斯達克級別」的特徵。

在過去 30 天裡,Hyperliquid 清算了 2056 億美元的永續合約名義成交額(按季度年化約 6170 億美元),但僅產生了 8030 萬美元的手續費收入,折算費率約為 3.9 個基點(bps)。

這意味著,Hyperliquid 的變現方式更接近於批發型執行場所(wholesale execution venue),而非面向散戶的高費率交易平台。

作為對比,Coinbase 在 2025 年第三季度錄得 2950 億美元的交易量,卻實現了 10.46 億美元的交易收入,隱含的抽成費率約為 35.5 個基點。

Robinhood 在加密業務上的變現邏輯與此相近:其 800 億美元的加密資產名義交易量帶來了 2.68 億美元的交易收入,隱含費率約 33.5 個基點;與此同時,Robinhood 在 2025 年第三季度的股票名義成交額則高達 6470 億美元。

整體來看,Hyperliquid 在成交規模上已跻身頂級交易基礎設施之列,但在費率與商業模式上,更像一個面向專業交易者的低抽成執行層,而非零售導向的平台。

差距不僅體現在費率水平上,更體現在變現維度的廣度。零售型平台往往能夠在多個收入「界面」上同時獲利。在 2025 年第三季度,Robinhood 共實現 7.30 億美元的交易相關收入,此外還有 4.56 億美元的淨利息收入,以及 8800 萬美元的其他收入(主要來自 Gold 訂閱服務)。

相比之下,Hyperliquid 目前對交易手續費的依賴程度要高得多,而且這些手續費在協議層面被結構性地壓縮在個位數基點區間。這意味著,Hyperliquid 的收入模型更集中、更單一,也更接近於低費率、高周轉的基礎設施型角色,而非通過多重產品線進行深度變現的零售平台。

這一本質上可以用定位差異來解釋:Coinbase 和 Robinhood 是券商 / 分銷型業務,依托資產負債表與訂閱體系進行多層變現;而 Hyperliquid 更接近交易所層。在傳統金融市場結構中,利潤池天生被拆分在這兩層之中。

券商(Broker-Dealer)vs 交易所(Exchange)模型

在傳統金融(TradFi)裡,最核心的分野是分銷層(distribution)與市場層(the market)的區隔。

像 Robinhood、Coinbase 這樣的零售平台,位於分銷層,能夠捕獲高毛利的變現面;而像 Nasdaq 這樣的交易所,位於市場層,其定價權在結構上受到限制,執行服務會被競爭壓向接近商品化的經濟模型。

券商 / 經紀商 = 分銷能力 + 客戶資產負債表

券商掌握的是客戶關係。大多數用戶並不會直接接入 Nasdaq,而是通過券商進入市場。券商負責開戶、托管、保證金與風險管理、客戶支持、稅務文件等,然後再將訂單路由到具體交易場所。

正是這種「關係所有權」,讓券商可以在交易之外進行多重變現:

  • 資金與資產餘額:現金歸集利差、保證金借貸、證券出借
  • 產品打包:訂閱服務、功能套餐、銀行卡 / 投顧產品
  • 路由經濟學:券商控制訂單流,可以在路由鏈條中嵌入支付或收入分成機制

這也是為什麼券商往往能賺得比交易場所更多:利潤池真正集中在「分銷 + 餘額」所在的位置。

交易所 = 撮合 + 規則 + 基礎設施,抽成受限

交易所運營的是交易場所本身:撮合引擎、市場規則、確定性執行以及基礎設施連接。其主要變現方式包括:

  • 交易手續費(在高流動性產品中持續被壓低)
  • 返佣 / 流動性激勵(往往為了爭奪流動性,將名義費率的大部分返還給做市方)
  • 行情數據、網路連接與機房共址
  • 上市費與指數授權

Robinhood 的訂單路由機制清楚地展示了這一結構:用戶關係由券商持有(Robinhood Securities),訂單再被路由至第三方市場中心,路由過程中的經濟利益在鏈條中分配。

真正的高毛利層在分銷端,它控制獲客、用戶關係,以及圍繞執行展開的一切變現面(如訂單流付費、保證金、證券出借和訂閱服務)。

納斯達克本身處在低利潤率(thin-margin)的那一層。它所提供的產品,本質上是高度商品化的執行能力與隊列訪問權,而其定價權在機制上被嚴格限制。

原因在於:為了爭奪流動性,交易場所往往需要將名義上的手續費以做市返佣(maker rebate)的形式大量返還;監管層面對接入費(access fee)設有上限,限制了可收取的費用空間;同時,訂單路由具有極高的彈性,資金和訂單可以迅速在不同交易場所之間切換,使任何單一場所有難以提高價格。

在納斯達克披露的財務數據中,這一點體現得非常直觀:其在現金股票交易中實際捕獲的淨收益,通常只是每股千分之幾美元的量級。這正是市場層交易所利潤空間被結構性壓縮的直接寫照。

這種低利潤率帶來的戰略後果,也清晰地反映在納斯達克的收入結構變化上。

在 2024 年,納斯達克的 Market Services(市場服務)收入為 10.20 億美元,占總收入 46.49 億美元的 22%;而這一比例在 2014 年曾高達 39.4%,在 2019 年也仍有 35%。

這一持續下滑的趨勢,與納斯達克主動從高度依賴市場波動、利潤受限的執行型業務,轉向更具經常性、可預測性的软件與數據業務高度一致。換言之,正是交易所層面結構性偏低的利潤空間,推動納斯達克逐步將成長重心,從「撮合與執行」遷移到「技術、數據與服務化產品」上。

Hyperliquid 作為「市場層」

Hyperliquid 約 4 個基點(bps)的有效抽成率,與其有意選擇的市場層(market layer)定位高度一致。它正在構建的是一個鏈上的「納斯達克式」交易基礎設施:

以 HyperCore 為核心的高吞吐撮合、保證金與清算體系,採用 maker / taker 定價與做市返佣機制,目標是最大化執行品質與共享流動性,而非面向零售用戶進行多層變現。

換言之,Hyperliquid 的設計重心不在訂閱、餘額或分銷型收入,而在於提供商品化但極致高效的執行與結算能力——這正是市場層的典型特徵,也是其低費率結構的必然結果。

這體現在 兩種大多數加密交易平台尚未真正落地、但在傳統金融(TradFi)中非常典型的結構性拆分上:

一是無需許可的券商 / 分銷層(Builder Codes)。

Builder Codes 允許第三方交易界面構建在核心交易場所之上,並自行收取經濟收益。其中,Builder 手續費設有明確上限:永續合約最高 0.1%(10 個基點),現貨最高 1%,且費用可以在單筆訂單級別進行設定。

這一機制由此構建了一個分銷層的競爭市場,而不是由單一官方應用壟斷用戶入口與變現權。

二是無需許可的上市 / 產品層(HIP-3)。

在傳統金融中,交易所通常掌控上市審批與產品創建。HIP-3 將這一職能外部化:開發者可以部署繼承 HyperCore 撮合引擎與 API 能力的永續合約,而具體市場的定義與運營由部署者自行負責。

在經濟結構上,HIP-3 明確了交易場所與產品層之間的收入分成關係:現貨與 HIP-3 永續合約的部署者,最多可保留其所部署資產交易手續費的 50%。

Builder Codes 已經在分銷端體現出成效:截至 12 月中旬,大約三分之一的用戶並非通過原生界面交易,而是通過第三方前端完成交易。

問題在於,這種有利於分銷擴張的結構,本身也會對交易場所層的抽成形成持續壓力:

1、定價被壓縮。

多個前端同時銷售同一套底層流動性,競爭自然會向最低的綜合交易成本收斂;而 Builder 手續費又可以在訂單級別靈活調節,進一步將價格推向下限。

2、變現面的流失。

前端掌握開戶、產品打包、訂閱服務和完整的交易工作流,由此捕獲券商層的高毛利空間;而 Hyperliquid 只能保留更薄的交易所層抽成。

3、戰略性的路由風險。

一旦前端演化為真正的跨場所路由器,Hyperliquid 就可能被迫進入批發式執行的競爭,只能通過降費或提高返佣來防守訂單流。

總體來看,Hyperliquid 正在有意識地選擇低利潤率的市場層定位(通過 HIP-3 與 Builder Codes),同時允許一個高利潤率的券商層在其之上成長。

如果 Builder 前端持續擴張,它們將越來越多地決定面向用戶的定價結構,掌握用戶留存與變現界面,並獲得路由層面的議價權,從結構上對 Hyperliquid 的抽成率形成長期壓力。

防守分銷權,並引入非交易所型利潤池

最直接的風險是商品化。

如果第三方前端能夠長期以更低價格壓過原生界面,甚至最終實現跨場所路由,Hyperliquid 就會被推向批發執行型經濟模型。

近期的一些設計調整顯示,Hyperliquid 正試圖在避免這一結局的同時,拓展新的收入來源。

分銷防守:保持原生前端在經濟上的競爭力

此前提出的一項質押折扣方案,允許 Builder 透過質押 HYPE 獲得最高 40% 的手續費折扣,這實際上為第三方前端提供了一條結構性地比 Hyperliquid 原生界面更便宜的路徑。對這一方案的撤回,等於取消了對外部分銷「壓價」的直接補貼。

同時,HIP-3 市場最初被定位為主要通過 Builder 分銷、而不在主前端展示;但現在,這些市場已經開始在 Hyperliquid 的原生前端中、以嚴格上幣標準進行展示。

這一信號非常明確:Hyperliquid 依然在 Builder 層保持無需許可,但不會以犧牲自身核心分銷權為代價。

USDH:從交易變現轉向「資金沉澱(float)」變現

USDH 的推出,旨在重新奪回原本會在體系外被攫取的穩定幣儲備收益。其公開結構為儲備收益五五分成:50% 歸 Hyperliquid,50% 用於 USDH 生態成長。同時,對 USDH 相關市場提供的交易費折扣進一步強化了這一取向:Hyperliquid 願意在單筆交易經濟性上讓利,換取一個規模更大、更具黏性的、與餘額綁定的利潤池。

從效果看,這等於為協議引入了一條類似年金的收入來源,其成長取決於貨幣基礎規模,而不僅僅是名義成交量。

組合保證金(Portfolio Margin):引入類似主經紀商的融資經濟學

組合保證金將現貨與永續合約的保證金統一,使不同敞口可以相互抵消,並引入了原生的借貸循環。

Hyperliquid 將保留借款人所支付利息的 10%,這使協議的經濟性越來越取決於槓桿使用率與利率水平,而不只是交易量。這更接近券商 / 主經紀商(prime)的收入模型,而非純交易所邏輯。

Hyperliquid 走向「券商式」經濟模型的路徑

在吞吐量層面,Hyperliquid 已經達到一線交易場所規模;但在變現上,它仍像市場層:極高的名義成交量,配合個位數基點的有效抽成率。與 Coinbase、Robinhood 之間的差距是結構性的。

零售平台位於券商層,掌握用戶關係與資金餘額,能夠同時變現多個利潤池(融資、閒置現金、訂閱);而純交易場所出售的是執行服務,在流動性與路由競爭下,執行天然趨於商品化,淨捕獲被持續壓縮。納斯達克正是這一約束的 TradFi 參照。

Hyperliquid 早期明顯向交易場所原型傾斜。通過拆分分銷層(Builder Codes)與產品創建層(HIP-3),它加速了生態擴張與市場覆蓋;代價是,這套架構也可能把經濟性向外推:一旦第三方前端決定綜合價格、並能跨場所路由,Hyperliquid 就有被壓成薄利批發執行軌道的風險。

不過,近期動作顯示出一次有意識的轉向:在不放棄統一執行與清算優勢的前提下,防守分銷權,並將收入來源拓展到「按餘額計」的利潤池。

具體而言:協議不再願意補貼外部前端在結構上比原生 UI 更便宜;HIP-3 更加原生化展示;並引入資產負債表式的收益來源。

USDH 將儲備收益拉回生態(五五分成,並對 USDH 市場給出費率折扣);組合保證金則通過對借款利息的 10% 抽成引入融資經濟學。

總體看,Hyperliquid 正在收斂到一種混合模型:以執行軌道為底座,在其上疊加分銷防守與餘額驅動的利潤池。這降低了被困在低基點、批發型交易場所的風險,同時在不犧牲統一執行與清算優勢的情況下,向券商式收入結構靠攏。

展望 2026 年,懸而未決的問題是:Hyperliquid 能否在不破壞其「外包友好」模型的前提下,進一步走向券商式經濟。USDH 是最清晰的試金石:在約 1 億美元供應量水平下,當協議不掌控分銷時,外包發行的擴張顯得偏慢。顯而易見的替代路徑,本可以是 UI 級預設——例如將約 40 億美元的 USDC 存量自動轉換為原生穩定幣(類似 Binance 對 BUSD 的自動轉換)。

如果 Hyperliquid 想要真正獲取券商層利潤池,它或許也需要券商式行為:更強的控制力、更緊密的原生產品整合,以及與生態團隊在分銷與餘額競爭上的更清晰邊界。

HYPE2.58%
查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)