---
title: CEX matching engine + cold/hot wallet 内部架構
aliases:
  - CEX matching engine architecture
  - CEX cold hot wallet design
  - Exchange order book + custody architecture
domain: exchanges
created: 2026-05-19
last_updated: 2026-07-29
last_tended: 2026-07-29
review_by: 2027-01-29
confidence: likely
tags:
  - exchanges
  - matching-engine
  - cold-storage
  - architecture
  - technical
sources:
  - https://www.nyse.com/
  - https://github.com/binance/
  - https://docs.safe.global/advanced/smart-account-signatures
  - https://csrc.nist.gov/pubs/fips/140-3/final
  - https://www.fireblocks.com/report/what-is-mpc
status: active
---

# CEX matching engine + cold/hot wallet 内部架構


## Wiki route

This entry sits under [[exchanges/INDEX|exchanges index]]. Read it against [[exchanges/jp-vasp-cold-storage-segregation-rules|国内 VASP コールド保管 95% + 分別管理制度]] for peer / contrast context and [[exchanges/fsa-vasp-registration-system|FSA 暗号資産交換業登録制度 — 番号体系・財務局管轄・登録要件]] for the broader system / regulatory boundary.

## 1. matching engine 概要

CEX のコア = **matching engine (注文書照合エンジン)**。設計思想は大別して 3 種類:

- **CLOB (Central Limit Order Book)** — 業界標準。買い注文と売り注文を価格・時間で照合。NYSE / NASDAQ から CEX まで踏襲
- **RFQ (Request for Quote)** — 機関 OTC 中心。bid/ask quote 要求 → 個別 fill
- **AMM-like** — DEX 系。AMM は CEX matching の代替設計 ([[exchanges/amm-design-evolution]] 参照)

CEX (Binance / Coinbase / bitFlyer / 国内全社) は CLOB 基盤。機関大口取引は別途 OTC desk で RFQ 処理。

## 2. CLOB matching engine 設計要素

| 要素 | 内容 |
|---|---|
| **FIFO (First-In First-Out)** | 同価格は時間優先で約定 |
| **price-time priority** | 価格優先 + 時間優先の 2 段階照合 |
| **iceberg orders** | 大口を分割表示し market impact 抑制 |
| **post-only / IOC / FOK** | 注文タイプ (maker only / Immediate-or-Cancel / Fill-or-Kill) |
| **co-location** | 機関 HFT 向け低遅延接続 (NYSE / Binance VIP) |

代表実装: **NYSE / Binance / Coinbase / dYdX v4 (Cosmos appchain)**。dYdX v4 は CLOB を on-chain validator 上で実装、CEX 性能と DEX 透明性の融合を試行。

## 3. RFQ / OTC engine

機関 OTC (**Cumberland / B2C2 / FalconX / Genesis (倒産)**) は CLOB ではなく **RFQ 方式**を採用:

- 顧客が "BTC 100 枚買いたい" と quote 要求
- マーケットメイカーが bid/ask 提示
- 個別 fill (order book に出ない)
- 大口取引で slippage 制御 + 価格秘匿

国内 OTC: bitFlyer / Coincheck が「販売所」名義で類似機能を一般顧客向けに提供 ([[exchanges/jp-cex-sales-vs-exchange-model-economics]] 参照)。

## 4. cold/hot wallet 内部架構

国内 VASP 義務 ([[exchanges/jp-vasp-cold-storage-segregation-rules]]) に基づく 3 層構成:

- **ホット ウォレット (≤ 5% 国内義務)** — matching engine 直結 · リアルタイム入出金処理 · maker/taker bot 連携 · API 経由で署名
- **ウォーム ウォレット** — 半オフライン · 大口出金時のステージング · 1 日複数回 cold から補充
- **コールド ウォレット (≥ 95% 国内義務)** — エアギャップ署名 · multi-sig (2-of-3 以上) · HSM または MPC 必須

Coincheck 2018 NEM 580 億円事件は「実質ホット 100%」の結果 ([[exchanges/coincheck-nem-hack-detailed-analysis]])。同事件後の規制強化で 3 層分離が国内義務化。

## 5. 主要技術スタック

署名・鍵管理で使われる代表的な技術カテゴリ ([[exchanges/global-institutional-custody-five-pillars]] / [[exchanges/jp-institutional-custody-three-pillars]]):

出典: 表全体は [Safe Signatures](https://docs.safe.global/advanced/smart-account-signatures)、[NIST FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final)、[Fireblocks MPC 解説](https://www.fireblocks.com/report/what-is-mpc)（2026-07-29 確認）に基づく。

| 技術 | 公開仕様の例 | 役割 |
|---|---|---|
| **multi-signature** | Safe smart-account signatures | 複数の owner 署名を設定可能なスマートアカウント方式。閾値は構成ごとに設定される |
| **HSM / cryptographic module** | NIST FIPS 140-3 | 暗号モジュールの設計・実装に対するセキュリティ要件と 4 段階のセキュリティレベルを定義 |
| **MPC** | Fireblocks MPC | private-key operation を複数 party の計算と key share に分散し、単一の完全な秘密鍵を一か所に保持しない方式 |

特定の CEX や custody provider が採用する署名方式、閾値、HSM / MPC 構成は変更され得るため、この表から個社実装を推定しない。個別事件の分析は [[exchanges/bybit-lazarus-hack-detailed-analysis]]、フォレンジック手法は [[security/bytecode-forensic-three-tier-verify|bytecode forensic 3-tier verify]] と [[security/forensic-identity-anchor-chain|forensic identity anchor chain]] を参照。

---

来源: 業界一般知識 + Binance / Coinbase tech blog + Gnosis Safe docs + Fireblocks whitepaper + Anchorage 公告。