中心化交易所(CEX)的保證金交易,是 24/7 配對引擎中風險最高、波動性最強的子系統。一次閃崩、一連串的強制平倉,或是不公平的追索,都可能將一個營運多年的平台拖入用戶信任危機與監管審查的漩渦。 SoonTech 的 CEX 保證金、風險與平倉引擎,旨在將「無壞帳追索」從一項口號,轉化為可稽核、可重現且符合監管機構要求的工程能力。 本文將系統性地剖析該引擎,涵蓋帳戶模型、保證金比率、分級保證金、標記價格與指數價格、平倉觸發條件與分階段平倉、ADL、追索權、交易前風險、清算群組、保險基金、跨帳戶保證金、監控與斷路機制,並為交易所營運商提供具體的實作路徑。

現貨配對僅處理交易執行與結算。保證金系統必須解答四個緊密關聯的問題:帳戶中有多少可用保證金、當前風險敞口有多大、何時必須強制平倉,以及若清算失敗,平台應如何處理壞帳。 錯誤的解答將引發連鎖反應:延遲平倉會耗盡保險基金;過早平倉會引發用戶投訴;笨拙的交易後處理(ADL)會招致社群媒體的憤怒;而過於激進的交易前檢查則會抑制交易量與深度。
對於白標營運商而言,保證金風險如今已具備監管與制度層面的重要性。成熟的做市商和自營交易部門將風險透明度視為合作夥伴關係的先決條件。 新加坡金管局(MAS)、香港證監會(SFC)、杜拜監管局(VARA)以及歐洲《市場基礎設施與中心化交易法》(MiCA)等監管機構,在審核牌照申請時,均會審查風險模型、壓力測試、保險基金規模及事件應變機制。 在與多個司法管轄區的持牌交易平台合作後,SoonTech 已建構出一套分層引擎,將帳戶模型分離、分級保證金、標價、分階段平倉、ADL、保險基金及結算叢集整合為單一且連貫的系統。
隔離保證金與跨帳戶保證金代表兩種不同的風險隔離理念。 在隔離保證金模式下,每個倉位均位於獨立的子帳戶中,並擁有專屬的權益、已用保證金、可用餘額及未實現損益。某個倉位發生平倉事件時,不會消耗其他倉位的資本,也不會由其他倉位的資本進行救援。這是一種保守且透明的模式,深受散戶及希望將客戶虧損局限于單一倉位的交易所青睞。
在跨帳戶保證金模式下,所有倉位共享單一權益池。總權益為各倉位未實現損益的總和;總已用保證金為各倉位初始保證金的總和;可用餘額則等於權益減去已用保證金,再減去任何被凍結的金額。 此模式允許獲利部位補貼虧損部位,從而大幅降低平倉機率;但若其中一個部位發生爆倉,將侵蝕其他部位的權益基礎。跨保證金機制非常適合已實施投資組合風險管理,且不希望因反覆發生孤立平倉而中斷操作的做市商與對沖基金。
SoonTech 的引擎透過單一帳戶引擎驅動這兩種模式。每個子帳戶皆獨立記錄凍結保證金、已實現損益、未實現損益及風險比率。 跨保證金帳戶本質上是一個彙總至主視圖的虛擬子帳戶。這種統一的抽象化設計讓營運人員能精細配置產品行為:現貨零售帳戶預設為隔離模式,永續合約專業用戶預設為跨保證金模式,機構用戶可選擇啟用投資組合保證金模式,而模擬與實盤環境則採用相同的風險計算邏輯。
初始保證金比率(IMR)是指用戶開倉時必須繳納的最低保證金,並決定最大槓桿倍數。 維持保證金比率(MMR)是指維持持倉所需的最低保證金。一旦帳戶權益跌破維持保證金要求,該持倉將進入平倉候選名單。帳戶的保證金比率(計算方式為權益除以持倉名目價值)顯示帳戶距離平倉線還有多遠。
假設有一筆多頭永續合約部位,帳戶權益為一千 USDT,名義價值為一萬 USDT,槓桿倍數為十倍。若初始保證金比率(IMR)設定為百分之十,則已繳納的一千 USDT即為初始保證金;若維持保證金比率(MMR)設定為百分之零點五,該部位則需五十 USDT 的維持保證金。 當未實現虧損達到 500 USDT 時,權益將降至 500 USDT。此時,引擎判定該帳戶已無法滿足維持保證金要求,該倉位便進入平倉候選隊列。
SoonTech 引擎會針對每筆部位計算 IMR 和 MMR,並在帳戶層級進行彙總。此外,該引擎還引入了一項風險比率,其計算方式為權益除以維持保證金要求。 風險比率低於一將觸發平倉,高於一則表示存在安全緩衝。風險比率讓前端介面與警示系統能使用共同的語言:越接近一表示風險越高,數值越大則表示越安全。
對所有用戶採用統一的保證金率,在規模擴大時效果不佳。若某用戶的名義價值達數億美元,且維持保證金率(MMR)僅為 0.5%,則任何市場異常都將使其面臨極高的風險暴露。即使微小但快速的價格波動,也可能在數秒內突破維持保證金線,導致保險基金面臨巨大的潛在損失。
分級保證金制度將最大允許持倉規模劃分為多個區間,每個區間的保證金要求皆隨規模增加而提高。 舉例來說,第一區間(不超過五百萬美元)可能要求 0.5% 的維持保證金;第二區間(五百萬至兩千萬美元)可能要求 1%;第三區間(兩千萬至一億美元)可能要求 1.5%;而超過一億美元的部位則可能要求 2% 或更高。
此機制具有雙重效果:其一,從經濟角度抑制過度集中,因為較大的持倉比例上需要更多資本,從而提高持倉成本;其二,將平倉風險分散至更寬的價格區間,讓風險引擎和做市商在市場崩盤前有更多時間介入。 SoonTech 支援按交易代號設定分級配置,並允許營運商按帳戶或持倉彙總風險敞口,防止使用者透過拆分帳戶或持倉來規避分級限制。
將最新成交價作為強制平倉觸發點是危險的。在深度不足的訂單簿中,最新成交價可能遭到操縱。 攻擊者可閃電式發布單邊極端報價,使價格飆升百分之十,進而觸發連鎖強制平倉。此類「蠟燭線攻擊」在 2020 年至 2024 年間曾引發數起撼動業界的爆倉事件。
SoonTech 引擎採用由基準價格與消失(或折價)區間組成的標價作為平倉參考。 基準價格即指數價格,其計算方式為多間主要現貨交易所即時報價的中位數,並過濾掉異常值,可選擇性地根據成交量或最新報價進行加權。消失區間在基準價格的上下方各保留百分之五的安全邊際。
若最新成交價向不利方向的波動幅度小於 5%,標價即等於基準價。若最新成交價持續朝持倉方不利方向波動超過 5%,標價將開始追蹤最新價格,但仍維持一定折扣,以避免因瞬間價格飆升而觸發清算。 此設計理念旨在將清算觸發條件與瞬時價格脫鉤,並迫使演算法僅對持續且顯著的偏離作出反應。
指數價格本身已針對單一交易所的干擾進行了強化防護。 SoonTech 預設從十至十五個主要現貨交易平台擷取數據,針對每個來源的延遲、報價過時程度及點差進行評分,剔除異常值,並透過成交量加權聚合或簡單中位數計算形成最終指數。在極端情況下,指數凍結機制會暫停特定時間區間內的更新,以防止基於過時數據做出決策。
平倉引擎是系統中反應最敏銳的執行單元。它並非單純將虧損帳戶的全部倉位以市價拋售至交易簿,而是根據風險嚴重程度進行排序,在價格保護機制下分批處理,並在適當時機由保險基金接管。典型流程如下:
首先,觸發檢測。風險引擎會定期掃描所有持倉,並生成風險比率低於一或維持保證金不足的帳戶清算候選名單。掃描間隔介於 10 至 100 毫秒之間:主要貨幣對的間隔較短,長尾貨幣對的間隔較長。
其次,批次下單。風險引擎不會針對整個持倉發出單一市價單,而是將剩餘可平倉數量切分成多個批次,每個批次均受「最小平倉規模」、「最大批次規模」及「最小報價點差」等參數所規範。批次化操作可降低市場衝擊,並避免對交易簿造成自損。
第三,價格保護。每筆批次限價單在提交前,都會經過滑點上限檢查。 平倉買單的價格不得高於標價乘以向上係數(例如 1.3%);平倉賣單的價格不得低於標價乘以下向係數。若價格突破保護上限,系統將針對該批次切換為市價單,並轉至下一批次。
第四,訂單簿凍結。批次限價單一經進入訂單簿,即會凍結對應帳戶的剩餘保證金,防止用戶在清算期間開立新倉位或取消並重新下單。凍結的保證金將於該批次完成時結算。
第五,保險基金接管。若批次限價單未能在合理的價格與時間閾值內成交,且帳戶風險持續惡化,保險基金模組將評估是否透過提交市價單或限價單來接管剩餘部位。接管閾值由基金規模、風險敞口及交易對手深度決定。
第六,結算與狀態報告。每筆平倉成交紀錄均會記錄於清算帳簿中,並更新帳戶的已實現損益、維持保證金要求及風險比率。若完全平倉後仍有剩餘保證金,將退還給用戶;若權益為負值,該倉位將進入追索流程。
當保險基金耗盡,且被平倉的部位仍導致權益為負時,平台將面臨壞帳風險。傳統上由平台自行承擔虧損的做法既不可持續,亦難以進行稽核。SoonTech 引擎採用三階段應對機制:首先動用保險基金,其次啟動自動去槓桿(ADL),最後作為最終手段實施社會化追索。
自動去槓桿(ADL)機制會將虧損分攤給從該被平倉部位中獲益的交易對手。這些交易對手即為該筆交易的反向持倉者,且其未實現利潤最大、槓桿率最高。 其經濟邏輯十分明確:既然他們從導致壞帳的價格波動中獲利,就應分擔部分損失。SoonTech 會根據「ADL 分數」(等於未實現損益乘以槓桿倍數)對候選對象進行排序。分數越高,該用戶被選中的機率就越大。
當 ADL 觸發時,被選中的用戶將被強制減持與壞賬金額相等的頭寸。相應的未實現損益將轉為已實現損益。ADL 並非強制平倉:它以標價執行,以避免更差的成交結果。 但 ADL 確實會剝奪用戶參與下一波行情的機會。因此,系統會在觸發 ADL 之前,盡可能動用保險基金來彌補壞帳。
社會化追索是最終的備用方案。若 ADL 無法彌補虧損,剩餘的負餘額將分攤給所有持有該標的頭寸的用戶。分攤方式可依據頭寸規模、未實現損益,或風險比率加權來決定。 每次追索事件都會記錄在稽核日誌中,並向監管機構及使用者公開。SoonTech 預設不啟用社會化追索機制,但會提供相關開關與參數,以便營運商能配合當地法規、使用者協議及平台風險偏好進行調整。
風險管理應在風險發生前進行。 SoonTech 引擎在下單、取消、修改及成交確認等階段均內建風險檢查機制。交易前檢查項目包括:帳戶是否具備足夠可用餘額以繳納初始保證金、該訂單是否會突破最大持倉限額、是否超過最大訂單規模、是否違反價格偏離上限,以及是否會觸發自營交易。
訂單簿保證金凍結是另一項關鍵機制。當使用者下達限價單時,引擎會根據最壞情況的成交情境凍結保證金。 買單會以掛單價格加上滑點緩衝區的價格凍結資金;賣單則以掛單價格減去滑點緩衝區的價格凍結資產。部分成交時,凍結的保證金將按比例釋放;取消訂單則會釋放全部凍結金額。此機制可避免發生「下單後無保證金,帳戶立即爆倉」的情況。
成交後雙重驗證是最後一道防線。即使經過交易前檢查,配對引擎仍會在確認成交前重新驗證帳戶。 檢查項目包括:帳戶是否因並行操作而資金耗盡、交易對手是否觸發強制平倉,以及成交價格是否在最新標價保護區間內。此機制可阻斷幽靈訂單與閃電爆倉。
SoonTech 亦實施取消與下單速率限制:每秒最大下單次數,以及每個帳戶每分鐘最大取消次數。異常帳戶將自動受到限流,或轉交人工審查。此前端管控機制,結合後端清算機制,共同形成完整的風險管控迴路。
清算叢集是保證金風險執行的核心骨幹。 它必須在不中斷配對引擎運作的情況下進行計算、評估與執行。SoonTech 採用具備熱備援功能的主動-被動叢集。主節點處理所有寫入操作,備用節點則透過訊息總線保持同步。當主節點發生故障時,備用節點將在數十毫秒內接管運作,且配對引擎不會受到切換影響。
該叢集透過帳戶分片實現水平擴展。每個分片處理帳戶的子集,分片依據使用者 ID 的雜湊值與代碼雜湊值的組合進行。此設計可將單一使用者的帳戶保留在同一個分片中,避免跨分片交易;同時也能將同一代碼相關的帳戶保留在同一個分片中,從而簡化總體風險評估。 營運人員可從上線時的一至兩個分片,逐步擴展至十至二十個分片。
清算叢集與配對引擎透過訊息總線進行通訊,藉此實現兩者之間的解耦。 配對引擎會發布成交事件;清算引擎則接收這些事件並更新帳戶資料。清算引擎會將凍結、解凍及平倉指令發送回配對引擎,由後者在訂單簿層級執行。這種分離讓配對引擎能專注於吞吐量,而清算引擎則專注於風險正確性,並透過統一的事件協定進行協調。
透過結合 Redis 記憶體內狀態與關係型資料庫,以維持交易一致性。如權益、保證金及風險比率等熱狀態資料,為提升效能而儲存於 Redis 中;關鍵變更則會寫入資料庫以供稽核。Redis 本身採用多重複本架構,並具備哨兵(Sentinel)故障轉移機制。 SoonTech 亦支援跨資料中心的多活躍節點部署。狀態以非同步方式同步,並透過版本號與冪等重播來保證最終一致性。
保險基金是平台用於應對壞帳的內部緩衝機制。SoonTech 為每個交易標的維持一個專屬的保險基金帳戶。資金來源包括:清算產生的剩餘結算盈餘、強制平倉時市場單與限價單之間的滑點收益、作為風險準備金注入的平台手續費百分比,以及合作做市商存入的風險保證金。
保險基金的規模必須根據各交易標的的風險敞口進行校準。常見的目標值為過去三十天平均名目價值的百分之零點五。當基金餘額低於目標值時,平台會從手續費帳戶轉入資金;當餘額超過目標值的數倍時,則暫停注資。 SoonTech 支援自動注資與警示功能,讓營運人員能根據其財務模型調整政策。
每項保險基金操作,包括清算接管、ADL 觸發及追索,均會連同時間戳記、交易代碼、帳戶 ID、觸發條件、金額及交易對手方 ID 一併記錄於稽核日誌中。日誌將長期冷儲存,並每日進行對帳,以供監管機構及第三方稽核人員查閱。
成熟的機構用戶不會僅集中於單一代幣。他們會跨多種幣種及多個市場進行對沖。SoonTech 支援投資組合保證金功能,可將現貨、永續合約及期權的持倉彙總至單一保證金計算中。該模型能識別對沖關係:若某帳戶持有 BTC 現貨多頭及 BTC 永續合約空頭,其淨曝險遠小於名義金額的總和。
投資組合保證金在技術上要求極高,需要穩定的相關性矩陣、波動率估算器以及壓力測試模型。 SoonTech 提供基於歷史數據校準的參數化模型,並允許操作人員整合第三方風險模型。投資組合保證金制度下的初始保證金要求通常高於獨立保證金,但維持保證金要求則顯著較低,這正是其對機構投資者極具吸引力的原因。
跨市場風險也提高了並發控制的門檻。當某個市場出現極端波動時,必須在數毫秒內重新計算其他市場的保證金要求。 SoonTech 提供統一的帳戶風險計算服務。各市場將持倉變動以事件形式發布;該服務則以流式處理的方式更新帳戶風險比率。此架構正是 SoonTech 將配對、配對後處理與風險管理三者分層隔離的關鍵。
風險系統絕不能是黑箱。操作人員必須能即時查看關鍵指標。SoonTech 的監控涵蓋三個層級。在帳戶層級,指標包括清算觸發條件、風險比率分佈、保險基金接管比率以及 ADL 發生頻率。 在標記層,指標包括按最後成交價計價的偏差、保險基金規模、平倉佇列長度以及平均平倉滑點。在平台層,指標包括每秒風險事件數、訊息總線延遲、清算分片負載以及 Redis 命中率。
警報依嚴重程度分級。第一級為資訊性:按最後成交價計價的偏差介於 2% 至 5% 之間時,將觸發預警通知。 第二級為警告:偏差超過 5% 或保險基金規模低於目標值的 80% 時,將觸發簡訊及聊天室警示。第三級為關鍵:保險基金即將耗盡、ADL 佇列積壓,或訊息總線嚴重延遲時,將觸發電話警示及斷路器機制。
斷路器是最後一道防線。SoonTech 支援全域性與單一標記的斷路器機制。全域性斷路器會暫停所有平倉與 ADL 操作,並將系統切換至「僅限平倉」模式;單一標記斷路器則會暫停該標記的新開倉與新掛單,但允許現有部位平倉並讓平倉操作繼續進行。 觸發條件、持續時間及恢復機制皆可自訂。操作人員必須定期演練斷路器啟動流程,以免實際事件發生時引發恐慌。
SoonTech 將上述所有功能整合為一個可配置、可觀察且可稽核的保證金與清算引擎,涵蓋白標中心化交易所所需的各項風險計算與執行能力。 該引擎以微服務形式部署,並可根據需求與撮合引擎、清算系統、MPC 錢包及流動性聚合功能整合。白標交付後,營運商可根據其規模、監管要求及用戶結構,選擇輕量級隔離型 + 單層級配置,或完整的跨層級 + 分層級 + 投資組合保證金配置。
其關鍵特點在於參數化設計。數百項參數(包括即時保證金比率(IMR)、最低保證金比率(MMR)、分級區間、消失帶寬、ADL 評分公式、保險基金注資比率及斷點閾值等)皆可透過管理主控台進行調整。變更將立即生效,並記錄於稽核日誌中。 針對不同司法管轄區,SoonTech 提供建議模板:對於監管嚴格的交易場所,採用更保守的 MMR 及更寬的波段範圍;針對以零售為導向的小型交易所,則採用 ADL 早期干預機制。
為確保高可用性,SoonTech 支援市內雙活躍(dual-active)及地理分散式多活躍(multi-active)部署。帳戶狀態由全域版本號控制,不同站點的清算分片可獨立運行,並進行異步對帳。SoonTech 還提供 24/7 全天候營運與事件應變服務,協助營運商應對極端事件。
對於計劃推出或升級保證金交易系統的營運商,SoonTech 團隊建議採取五至六個步驟:
SoonTech 團隊期待與持牌交易所、機構級做市商及 Web3 團隊合作,將「無壞帳追索」打造為中心化交易所(CEX)產業的基礎設施基準標準。
A:當用戶帳戶在平倉後權益仍為負值時,即發生「壞帳追索」,這意味著用戶的損失已超過所有可用保證金。 這是任何中心化交易所(CEX)面臨的核心風險管理問題。SoonTech 引擎透過三層機制處理壞帳:保險基金、ADL,以及作為最後手段的社會化追索。
A:當保險基金耗盡,且被平倉的部位仍導致權益為負值時,通常會觸發 ADL。 系統會根據 ADL 分數對交易對手進行排序,分數越高表示對手方是獲利更多且槓桿更高的用戶。SoonTech 引擎會在觸發 ADL 之前,盡可能利用保險基金彌補壞帳,從而將強制減持的頻率和規模降至最低。
A:理論上,是的。 在交叉保證金帳戶中,所有部位共用同一保證金池。某個部位的大幅虧損可能侵蝕其他部位的權益基礎,並觸發進一步的平倉。因此,SoonTech 建議機構用戶將交叉保證金與能識別對沖策略的投資組合保證金模式搭配使用,並建議操作者採用具相關性意識的風險降低策略,以降低連鎖反應發生的機率。
A:在成交量薄的市場中,最新成交價容易遭到操縱。若直接將其作為平倉觸發條件,攻擊者便可能透過閃電報價使價格飆升百分之十,進而觸發連鎖平倉。 SoonTech 採用由指數價格加上 5% 消失帶所構成的標價,因此強制平倉機制僅對持續且顯著的偏離作出反應,而非對瞬間的價格波動作出反應。
A:保險基金主要有四項來源:清算產生的剩餘結算盈餘、強制平倉時市價單與限價單之間的滑點收益、作為風險準備金注入的平台手續費百分比,以及合作做市商存入的風險保證金。 SoonTech 引擎會為每個代幣維護專屬的基金帳戶,並支援自動注入與警示機制,以維持基金在健康的規模。
A:最直接的方法是使用較低的槓桿、控制倉位規模,並避免極端單邊押注。SoonTech 引擎在篩選 ADL 候選對象時,會優先考慮高損益、高槓桿且持相反方向倉位的用戶,因此倉位規模小、槓桿低且長期持有的用戶被選中的機率極低。 該引擎還會利用保險基金在觸發 ADL 之前盡可能彌補壞帳,從而將強制減倉的頻率與規模降至最低。
保證金風險是中心化交易所(CEX)工程中最棘手的問題。這需要匹配、清算、風險管理及營運部門之間的長期協作,並從帳戶模型到斷路機制進行持續優化。 SoonTech 期待與全球營運商攜手合作,將「無壞帳追索」打造為可驗證、可稽核且符合監管要求的基礎設施能力。
🌐 與 SoonTech 攜手打造安全且可擴展的 Web3 平台。
探索我們針對白標加密貨幣交易所、預測市場、多方隱私計算(MPC)錢包、配對引擎、流動性整合及合規性的解決方案。