六層穩定幣堆疊把混亂變地圖

以前我把穩定幣當一團雜訊，現在我會先拆成六層再看。

我盯穩定幣基礎設施一陣子了，老實說，一開始很煩。每家 vendor 都在講自己能做 payments、custody、compliance，講得像這幾個字本來就同一件事。結果我每次開會都像在拆一袋混在一起的零件：今天是 issuer，明天是 wallet，後天又冒出一個 reserve fund，還有人把法遵包裝成支付產品。最討厭的是，大家都很有自信，但沒人把邊界講清楚。architecture review 變成政治協調會，慢得要命。

後來我換了一個看法：不要把穩定幣當單一市場，把它當六層商業堆疊。這個轉法很土，但真的有用。你一旦開始問「錢在哪一層移動」「風險在哪一層停住」「誰在買差異化，誰只是在租基礎設施」，很多模糊話術就會自己現形。這篇就是我把這個地圖拆給你看，順手做成你可以直接拿去評估產品、供應商、或內部架構的版本。

我這次拆解的外部錨點是 Stablecoin Infrastructure Landscape 2026，作者是 Marko Savic。這篇不是那種喊口號的文，它是把市場按層級攤開來看：issuer、custody、orchestration、payment apps、tokenized assets、compliance。後面我用這個骨架，翻成我自己會拿來做決策的語言。

先別再把所有東西都叫 stablecoin platform

“The stablecoin infrastructure stack has matured from a two-layer market of issuers and exchanges into a six-layer commercial ecosystem covering issuance, custody, orchestration, payment applications, tokenized assets, and regulatory compliance infrastructure.”

這句話翻成白話，就是：穩定幣基礎設施早就不是「發幣＋交易所」兩件事而已，它已經變成一個有分工的堆疊。堆疊有邊界，有上下游，有不同買家。你如果把它們全混在一起，就會拿 custody 去比 payment app，拿 issuer 去比 compliance vendor，最後只會得到一堆錯誤對照。

我之前幫一個支付產品畫穩定幣導入圖，第一版就是災難。每個 vendor 都說自己 end-to-end，我一開始還真的差點信了。後來我把層級切開，問題立刻變簡單：issuer 管 token，custody 管 key，orchestration 管路由和抽象，app 管使用流程，tokenized assets 管資金停泊，compliance 管你能不能合法賣出去。誰要是說自己全包，我反而更想看細節。

這篇文章有用的地方，不是它把名詞講得很漂亮，而是它逼你用商業功能去看市場，而不是用品牌去看市場。這件事在 2026 特別重要，因為這一層的玩家已經不是小圈圈實驗品了，像 Circle、Tether、Fireblocks、Stripe、BNY Mellon，各自都卡在不同層。

實操上我會這樣做：每看一個 vendor，就先寫下它屬於哪一層、明確不屬於哪一層。只要答案開始含糊，八成就是有問題。架構討論時我甚至會強迫團隊直接標註：issuer、custody、orchestration、app、asset、compliance。這招很土，但很有效，因為它會逼大家停止講空話。

Issuer 是最顯眼的那層，也是最容易被誤解的那層

Layer 1: Stablecoin Issuers

issuer 做的事很簡單：發行和管理 token。但你真的碰過規模後就知道，這件事一點都不簡單。token 本身只是表面，後面還有 reserves、法律結構、分發管道、贖回機制，少一個都會出事。文章把幾個代表講得很清楚：Tether 在新興市場零售流動性很強，Circle 的 USDC 是機構常用選項，Paxos 做白標發行，Ripple 則是把 RLUSD 往受監管通道推。

真正關鍵的不是誰發得多，而是誰能進得了受監管流程。文章提到 USDT 沒有 GENIUS Act 合規，也沒有 MiCA 授權；Circle 則同時有 GENIUS Act 對齊和 MiCA 授權。這種差異會直接改變採購會議的走向。財務團隊可能愛 USDT 的流動性，但你的平台如果在受監管環境裡跑，很多時候就是不能碰，或至少不能照同樣方式碰。

我看過不少團隊把「供給量大」直接當成「最適合我們」。這很偷懶。供給量只告訴你市場已經在哪裡，不告訴你你的產品能不能合法、穩定、體面地用它。2026 之後，這三件事差很多。

實操上，我會先看三件事：儲備透明度、牌照或授權範圍、以及跟目標地區的分發相容性。如果你做 EU，MiCA 就是硬門檻；如果你做美國機構客戶，GENIUS Act 對齊就不能只寫在簡報上；如果你做新興市場零售流量，原始流動性和錢包滲透率通常比包裝漂亮更重要。

• 做受監管產品，先看授權和 attestation，不要先看行銷頁。
• 做消費支付，先看這顆 stablecoin 在目標市場有沒有錢包密度。
• 做品牌產品，白標發行常常比自己從零搭快很多。

Custody 是穩定幣專案開始變真的地方

Layer 2: Custody and Security Infrastructure

這一層是我最不信簡報、最愛問細節的地方。誰拿 key、誰能批交易、誰可以凍結、誰可以回滾、誰出事負責，這些都不是小問題。custody 很無聊，直到它出事，然後它就會變成整個故事。文章把 Fireblocks、Anchorage Digital、BNY Mellon 放在這層，邏輯很順，因為這層賣的不是酷，而是控制和信任。

白話一點說，銀行和資產管理人要能碰穩定幣，前提是數位資產操作要像一般風控金融那樣可管理。Fireblocks 強在 MPC 和操作控制，Anchorage 有 OCC charter 的 trust bank 架構，BNY Mellon 則是傳統 custody 的重量級代表。路徑不同，但目的都一樣：讓資產安全到可以被大機構碰。

我在企業案子裡最常看到的拉扯，就是產品團隊想快，風控團隊想多一層、兩層、三層控制。這很煩，但也正常。好的 custody 不是幫你消滅這個矛盾，而是把矛盾變成可討論的控制點。差的 custody 只會讓大家一直說「應該沒問題吧」。

實操上，如果你的場景有 treasury、settlement 或機構餘額，就不要把 custody 當 checkbox。你要問的是：有沒有 policy controls、交易模擬、角色式審批、audit trail。如果答案很飄，先停。你在美國的話，還要問背後是什麼 charter、什麼監管包裝，因為採購真的走到後面，這些才是會卡住的地方。

文章還提到 Fireblocks 的 Payment Engine 和 Agentic Payments Suite，這也提醒我一件事：custody vendor 現在也在往 orchestration 上爬。可以，但我還是會保留層級觀念。加功能不代表分類消失，這點很多人會偷懶。

Orchestration 才是把工程團隊從整合地獄裡救出來的層

Layer 3: Payment Orchestration Platforms

orchestration 是整個堆疊開始變實用的地方。它卡在 issuer 和終端使用者之間，把 chain 選擇、合規檢查、法幣兌換、路由邏輯包成 API。文章點到 Bridge、Crossmint、Zero Hash、Orbital、Mural Pay、MassPay，還有 Coinbase 相關整合。

白話翻譯就是：這一層把「我們可以送 token」變成「我們可以跑一個業務流程」。這差很多。送 token 是 blockchain 問題，幫供應商付款、跨國 payout、又要讓法遵點頭，這是系統問題。orchestration 就是在這兩個世界中間幫你吞掉複雜度。

我最喜歡 Bridge 這個例子，因為它很直接地告訴你市場已經走到哪裡。文章寫 Stripe 以 11 億美元收購 Bridge，然後把它當 API-first 的 stablecoin payment layer，再搭配 Open Issuance 做品牌發行。這代表市場不再只是試水溫，而是在包裝、產品化。Stripe 都進來了，其他人就不能再只拿 spreadsheet 當產品。

實操上，如果你做的是會碰 stablecoin 的產品，但你不想自己變成 blockchain routing 公司，就該用 orchestration layer。你買的是上市時間、合規抽象、以及多 rails 支援。比較供應商時，請直接看支援地區、payout 方式、fiat on/off-ramp、以及它到底替你吞掉多少合規工作。

• 需要快，就用 orchestration，不要自己寫 chain logic。
• 需要高度控制或自訂經濟模型，才考慮直接接 issuer。
• 有全球業務時，先確認 state、country、sanctions coverage。

Payment app 是穩定幣變正常的那一層

Layer 4: Consumer and Enterprise Payment Applications

很多團隊看到這層就想跳過，因為它看起來比較像產品，不像 infrastructure。偏偏就是這層決定 stablecoin 能不能離開 crypto 圈。文章把這層涵蓋的東西列得很實在：consumer wallet、merchant checkout、payroll、remittance、payout tools。講白了，就是讓財務團隊、承包商、客戶真的碰得到。

這層的重點不是鏈，而是流程和介面。只要使用者還得面對 seed phrase、地址格式、手動確認、奇怪的錯誤訊息，多數正常企業都會退。大家想要的是付款給供應商、幫員工或承包商發錢、收款對帳，不是學一套新宗教。

我最常在 contractor payout 流程看到這件事。工程團隊會先吵 chain 選哪條，但財務只在乎：錢有沒有到、匯率有沒有太爛、對方能不能自己提現、出了問題要找誰。這才是產品面。你如果忽略這層，前面做得再漂亮，最後也只會停在 pilot。

實操上，payment app 應該圍繞 job to be done 設計，不要圍繞 asset class 設計。B2B 通常要 invoice、approval、payout status、reconciliation；consumer flow 則要 wallet 簡單、餘額清楚、cash-out 便宜。stablecoin rail 可以藏在後面，但前台得像正常金融軟體，不然沒人要用。

文章提到 enterprise payout 能覆蓋 180 個國家，靠 USDC 結算。這種例子其實很直白：全球覆蓋不是看你支援幾條鏈，而是看你能不能真的把錢送到對方手上，而且不用三通客服。

Tokenized assets 把穩定幣市場拉到資金管理這邊來了

Layer 5: Tokenized Assets

這層讓整個市場看起來不只是 payments。文章提到，tokenized Treasury products 在 2026 年 6 月突破 70 億美元鏈上資產，BlackRock 的 BUIDL 領先，Fidelity、State Street、Invesco 也開始進場。這不是支線，這是資本市場故事直接跟支付故事黏在一起。

白話一點說，穩定幣基礎設施不只是在搬美元，也是在處理「美元暫時放哪裡」。tokenized Treasuries 和 reserve funds 把 cash management 變成 on-chain 產品。這會直接影響你怎麼看 yield、流動性、以及 treasury 操作。

我喜歡這一層，因為它解釋了為什麼這市場突然變擠。當 tokenized fund 開始變得可信，穩定幣堆疊就不再只是支付 rail 的故事，而是更大的 balance-sheet story。資產管理人、custodian、銀行都被拉進來了，因為這不是純 crypto 小圈圈能自己玩的東西。

實操上，如果你在做 treasury tooling，把 tokenized assets 看成 liquidity stack 的一部分，不要把它當新奇玩具。你要問的是：資產多久能動、贖回路徑是什麼、風險政策能不能接受。如果它比你原本的現金管理還麻煩，那就別硬上。

我也會特別小心 yield 行銷。文章提到有些產品會做 reserve yield sharing 或 partner-owned yield，這不奇怪，但如果一個產品只剩 yield 可講，我大概會先假設後面會有麻煩。treasury product 先解決操作需求，再談經濟性，順序不要反過來。

Compliance 已經是產品層，不是法務備註

Layer 6: Regulatory Compliance Infrastructure

這一層以前常常被藏在 legal review 裡，現在直接進產品規劃。文章把 2026 的變化跟 GENIUS Act、MiCA、以及日本 JFSA 框架串在一起，這很重要，因為監管已經不是單純的阻礙，而是市場分層器。能不能做、能在哪裡做、能不能賣給大客戶，全部都被它切開了。

白話翻譯就是：compliance infrastructure 現在是商業護城河。你能不能證明 licensing、authorization、attestation、sanctions screening、auditability，會直接影響你能不能賣給大客戶。做不到的話，你就會一直待在「很有趣的 pilot」那一格，永遠出不來。

我看過不少團隊先把產品做漂亮，結果後面才發現法務不能簽、採購要更多文件、客戶風控要 licensing matrix。這不是產品小 bug，這是類別問題。2026 的穩定幣市場，終於願意把這件事講白。

實操上，我會把 compliance 當架構來畫：先把每個客戶地區對應到適用法規，再把每個 vendor 對應到它真的拿到的批准。不要假設供應商官網寫全球可用，就真的全球可用。你如果賣歐洲，MiCA 不是可選；你如果賣日本，JFSA 不是加分項；你如果賣美國機構客戶，監管對齊要寫清楚，不要靠暗示。

我喜歡這篇的另一點，是它沒有把所有 compliance 混成一鍋。issuer authorization、payment institution status、custody charter、licensing footprint，這些不是同一件事。真實系統裡，它們是不同失敗模式，也需要不同答案。

可抄的模板

# Stablecoin infrastructure map template

Use this to evaluate a stablecoin product, vendor, or internal architecture.

## 1) Define the use case
- Primary job: [payments / treasury / payouts / remittance / settlement / reserves]
- Target users: [consumers / merchants / finance teams / institutions / developers]
- Target geographies: [US / EU / UK / Japan / LATAM / APAC / global]
- Risk tolerance: [low / medium / high]

## 2) Map the six layers

### Layer 1: Issuer
- Candidate issuer(s):
- Stablecoin(s):
- Reserve model:
- Licensing / authorization:
- Redemption path:
- Notes on supply / liquidity:

### Layer 2: Custody and security
- Custody provider:
- Key management model:
- Approval workflow:
- Audit trail support:
- Incident response owner:

### Layer 3: Orchestration
- Orchestration provider:
- Chains supported:
- Fiat on/off-ramps:
- Compliance screening:
- Routing / fallback logic:
- Reconciliation support:

### Layer 4: Payment application
- User interface:
- Workflow supported:
- Payout / checkout / payroll / remittance:
- Support burden:
- Reconciliation/export format:

### Layer 5: Tokenized assets
- Treasury / reserve product:
- Yield model:
- Liquidity / redemption terms:
- Settlement timing:
- Risk policy fit:

### Layer 6: Compliance infrastructure
- Applicable regime(s):
- Licenses / charters / authorizations:
- Sanctions / AML / KYC controls:
- Reporting / audit requirements:
- Geography restrictions:

## 3) Vendor scorecard
Score each 1-5.
- Regulatory fit:
- Operational fit:
- Developer effort:
- Treasury fit:
- Customer fit:
- Geographic coverage:
- Cost:
- Exit risk:

## 4) Decision rule
- Use if:
- Avoid if:
- Revisit when:

## 5) Red flags
- Claims end-to-end coverage but cannot name the layer.
- No clear licensing or authorization story.
- Compliance is described as “handled” but not documented.
- Treasury yield is marketed more heavily than operational utility.
- The product requires your team to become blockchain ops experts.

## 6) Example summary
We are using [issuer] for token creation, [custody provider] for key control, [orchestration provider] for routing and compliance abstraction, [payment app] for end-user workflows, [tokenized asset] for treasury management, and [compliance infrastructure] for jurisdiction coverage.

如果是我自己在 review 會議上用，我會在 demo 前就先填這張表，不會等 vendor 講完才填。因為人一旦被 demo 搞暈，就很容易忘記問那些麻煩但真正重要的問題。這個模板的作用，就是把那些麻煩問題提前拉出來。

我這篇的原始來源是 Stablecoin Infrastructure Landscape 2026。六層結構和部分玩家整理是從那篇來的；我加上的判斷框架、選型問題、和模板，都是我自己整理給開發者和產品團隊用的版本。