Thierry Design Portfolio - Apollo, BTC Cross-chain Protocol

Apollo 是一個跨鏈協議，將比特幣流動性引入 Solana。我重新設計了跨鏈存款流程，將像「建立存款地址」這樣的技術功能，轉化為用戶熟悉的中心化交易所存款體驗，降低跨鏈體驗摩擦，並為想使用 Solana DeFi 的比特幣持有者建立信任感。

介面設計

體驗設計

產品策略

2024/10 - 2025/09

專案概覽

合作客戶

專案時間

角色

Optimizing the

BTC-to-Solana Wrapped Asset Experience

The Story

Apollo 是 Zeus Network 打造的一套跨鏈 Bitcoin 入口。使用者可以將原生比特幣（BTC）鎖定在 Bitcoin 主網，並在 Solana 上鑄造等值的 zBTC，讓原本「閒置於錢包中的數位黃金」，首次能參與 Solana 上高速、低成本的 DeFi 生態。雖然比特幣依然是最受信任的數位資產，但主網的技術限制導致大部分 BTC 流動性被長期閒置。Apollo 的設計目標，就是釋放這股沉睡的流動性，讓使用者能夠在 Solana 上鑄造 zBTC 並投入各種 DeFi 應用之中。

然而到了 2025 年，封裝 BTC 市場並未降溫，反而變得更加成熟、競爭更激烈。zBTC 的擴張受限於其鑄造流程僅依賴原生 BTC 存入，形成較高的進入門檻；跨鏈等待時間也造成心理摩擦，讓新用戶在導入流程中容易猶豫；而 zBTC 僅在 Solana 上流通的設計則使 zBTC 難以吸引多數持有 USDC／USDT 的主流 DeFi 使用者。

結果，Apollo 上線後的 zBTC 流通量未達預期，機構合作進展比排程更慢，整體採用曲線也陷入停滯。挑戰因此轉向：如何降低跨鏈摩擦、重新思考使用者動機，並吸引不限於 BTC 持有者的全新資金來源，才能真正突破冷啟動困境。

the Challenge

手機上的跨鏈體驗

Apollo 的鑄幣與贖回同時涉及 Bitcoin 與 Solana，操作流程繁瑣且資訊量龐大。作為一款去中心化應用（dApp），使用者必須透過加密貨幣錢包內建的 In-App Browser 進行操作。然而，Apollo 的早期設計要求使用者同時在同一個錢包應用中連結 Bitcoin 與 Solana 錢包而目前市面上能支援此功能的錢包極少，僅有 Phantom 或部分交易所錢包具備跨鏈支援。這樣的設計限制讓多數使用者在行動端難以完成鑄幣操作，也使錢包連結、交易確認與等待提示等關鍵互動變得不直覺。

我們該如何在有限的操作空間中，重構跨鏈體驗，讓使用者能安心完成流程？

如何將技術上額外的步驟轉變為潛在機會？

在早期的智能合約架構中，使用者必須先將 BTC 存入一個暫時性的保管庫（Hot Reserve），系統再解析他們的 Solana 地址來完成 zBTC 鑄造。由於每筆比特幣交易都需要約 10 分鐘的確認時間，整個流程可能長達一小時，帶來不佳的等待體驗。

為了改善這個問題，工程團隊升級了底層架構，讓使用者在首次使用時即可建立一個綁定 Solana 錢包的專屬存款地址。如此一來，BTC 可以直接進入冷錢包（Cold Reserve），整體等待時間也縮短至約 30 分鐘。

然而，這項改善也帶來了新的設計挑戰—「使用者現在必須額外支付一筆費用來生成這個存款地址，而這並不是大部分 DeFi 產品中的常見行為。」對設計師來說，核心問題就變成：

我們該如何重新定位這個設定步驟，讓用戶理解：這筆「建立地址的費用」不是阻礙，而是為安全且順暢的跨鏈體驗所做的必要投資？

Market & User Analysis

Apollo 上線後的 zBTC 鑄造量長期維持在低檔，顯示產品尚未被市場採納。更令人意外的是，7 月 1 日出現一筆 18 cbBTC → BTC 的巨額贖回，占了整體儲備的近 10%。由於 Apollo 主打 Permissionless 機制，允許任何在鏈上具有儲備證明的 wrapped BTC 無需 KYC 即可兌回原生 BTC，系統雖然如設計般開放運作，但也暴露出另一層風險：

去中心化帶來了信任，也削弱了儲備控管的主動性。 這起事件促使團隊緊急設定每日出金上限，同時讓我開始重新思考：

誰是 Apollo 的用戶？
Wrapped BTC 的用戶投資動機是什麼？
我們跟其他的競品差異在哪裡？

Question 1.

誰是 Apollo 的用戶？

辨識 Apollo 的使用者比預期中更困難。
根據 Growth Team 從鏈上數據分析，多數 zBTC 的持有者是透過 Swap 取得，而非自行鑄造 (Mint)，這代表許多使用者將 zBTC 視為一種可流通的代幣資產，而非透過存入原生 BTC 來參與協議。
在出金（Withdrawal）端，數據顯示有一群頻繁進行套利的鏈上交易團隊，在完成一輪套利後，會將資產轉換回 zBTC，並透過 Apollo 的 Permissionless 出金機制兌回原生 BTC。
這些使用者多為熟悉跨鏈與資金效率操作的 DeFi 資深玩家，他們看重 Apollo 無需 KYC 就能轉回原生 BTC 的彈性與自由。  然而，入金端的行為則更難以界定。
由於團隊並未安排用戶訪談或問卷，加上 BTC 持有者注重隱匿性，我只能從社群觀察推測：
「部分使用者出於好奇或「玩票性質」嘗試產品，另一部分則是受到行銷活動與獎勵池吸引，為了獲取短期收益而參與。」  

整體來看，Apollo 的使用者輪廓呈現出高度碎片化：一端是將 Apollo 視為套利工具的 DeFi 老手、另一端是因獎勵與新奇性而短期參與的散戶。而這樣的現象揭示了一個根本問題：

Apollo 缺乏明確的核心用戶群，也使得產品策略與長期定位難以聚焦

Question 2.

Wrapped BTC 的用戶投資動機是什麼？

zBTC

Zeus

cbBTC

Coinbase

xBTC

OKX

由於缺乏鏈上數據分析資源，我結合 Growth Team 的市場回報，並使用 Perplexity 與 Grok AI 輔助研究，以了解 Wrapped BTC 的市場定位與使用者輪廓。
透過 Grok 的任務功能，我追蹤 zBTC、cbBTC、xBTC 三種產品的每日討論與新聞動向，發現 cbBTC 與 xBTC 的敘事多聚焦於「多鏈串接」，而 zBTC 則主打「Permissionless」與「無需 KYC」。這讓我開始思考：

Permissionless 真的是封裝比特幣使用者在意的價值嗎？

進一步分析市場聲量與使用者行為後，我發現封裝比特幣用戶與 BTC 持有者有明顯差異。他們多以 USDC/USDT 為核心資產的 DeFi 玩家，熟悉槓桿、借貸、質押等操作，收益多以 USDC 結算。這群用戶追求的是「流動性」與「資金效率」，而非長期持有比特幣的價值儲存。  
對 Apollo 而言，這樣的洞察揭示出一個根本問題—產品的「去中心化、無需 KYC」優勢，並非這群用戶的主要驅動因素。當潛在受眾幾乎與 BTC 持有者不重疊時，Apollo 必須重新定義 zBTC 的市場價值與溝通語言。

Question 3.

我們跟其他的競品差異在哪裡？

cbBTC

xBTC

zBTC

跨鏈成本 & 可用性

DeFi 流動性 &
年化收益

Mint 規模 & 供應量

整體採用優勢

非常低
內建跨鏈橋

高
TVL $1B 以上
低滑點

高
4.6B USD BTC
backed

最高

高流動性與多鏈支援

中等
LayerZero

中等
TVL $300–400M

中等
$200–400M

好

很高的拓展潛力
但市場分額較低

中等～低
未支援多鏈

中低
TVL 僅有幾千萬

低

低於 1000 BTC

普通
很強的去中心化敘事
但缺乏規模擴張

封裝比特幣（Wrapped BTC）的投資邏輯更接近金融商品，如同藍籌股般，以「長期價值儲存」與「穩定增值」為核心，同時兼具金融操作的收益可能。
然而，在 Zeus 的內部定位中，zBTC 的生態採用與推廣多被視為一種「行銷合作資源」，而非以金融產品邏輯長期經營的資產。這使得產品缺乏明確的市場策略與持續的用戶洞察，難以建立信任與價值基礎。

相較於 wBTC、cbBTC、xBTC 等具備託管機構、交易所背書與高流動性的競品，zBTC 雖主打「Permissionless」與「無需 KYC」的去中心化特性，卻難以吸引追求收益與穩定性的 DeFi 用戶。

我們該如何在競爭激烈且信任壁壘高的市場中，讓 zBTC 的「去中心化」特質成為差異化優勢，而非採用障礙？

Design iterations

previous design

MVP Version

在早期的設計中，Apollo 要求使用者先連結 Solana 錢包，接著再綁定一個 Bitcoin 錢包地址以建立收款帳戶。每個 Bitcoin 與 Solana 錢包的組合都會生成一組專屬的「存、取款帳戶」，這樣的設計確保了鏈上資產的安全與對應性，但也帶來了明顯的使用摩擦：使用者每次進入系統時，都必須重新綁定正確的錢包組合才能操作。

團隊很快發現，這樣的帳戶結構對行動端使用者特別不友善，因為在 Solana 鏈上，只有 Phantom Wallet 同時支援 Bitcoin 與 Solana，因而我們不得不阻擋手機端上用戶使用 Apollo（無法操作）。而 Web3 多數用戶是手機原生用戶，通常是從 X（Twitter）上看到 DeFi 短期高收益活動而被吸引而來，這些潛在用戶大多使用手機錢包操作 dApp；Apollo 的架構迫使他們只能回到桌機上操作跨鏈，因而產品的成長速度遠低於預期。

此外，初期的鑄幣流程也缺乏即時性，早期的合約為了辨識存款方地址，BTC 需要經過兩道存款手續，需要經過 6 個比特幣區塊確認（耗時 60 分鐘），完成鑄幣後 zBTC 會先被傳送至中繼地址，使用者要再回到 Apollo 手動將資產領回錢包，才能正式在 Solana DeFi 上使用。這樣複雜且耗時的操作，使得上線初期雖然有不少人因為好奇參與鑄幣，在不久後使用者熱度卻迅速消退， Apollo 在短暫的話題高峰後，鑄幣量成長逐漸趨緩。

在 Apollo 上創立存款帳戶

當使用者連結一個新的 Bitcoin 錢包後，他們需要綁定 Solana 錢包以建立一組「存款／提款專用帳戶」。

需要同時連結兩個錢包進行跨鏈

必須同時連結 Solana 與 Bitcoin 錢包才能建立收款帳戶。他們可以選擇重新連結先前綁定過的錢包組合，或建立新的配對，但這樣的操作流程對初次使用者來說過於繁瑣。

視覺層級問題

然而，「處理中交易（Pending Transaction）」的進度面板位於首屏下方，容易被忽略；同時，右上角的
「成功（Success!）」通知更為醒目，讓使用者誤以為鑄幣流程已經完成。

容易誤導用戶的狀態

介面顯示的「Success」訊息僅代表 Solana 端
交易已確認，但實際上，鑄幣流程必須等到 Bitcoin 與 Solana 兩條鏈的交易都完成後才算
結束。這樣的提示容易讓使用者誤以為鑄幣已
完成。

previous design

Version 2.

Web3 的產品體驗高度仰賴於底層合約的設計，而在這次改版中由於底層合約升級，我們導入了「存款地址」這樣的設計，這個地址能讓使用者能建立「綁定當前連結的 Solana 錢包」的 Bitcoin 收款地址。使用者向該地址發送 BTC 後，所有鑄造完成的 zBTC 都會自動傳送至以配對的 Solana 錢包地址，且整個過程僅需等待 Bitcoin 鏈上三個區塊確認，大幅縮短鑄幣時間。

而產品設計也需要因應新的鑄幣方式做出設計，必須同時考量「直接使用介面存款」以及「直接存入該存款地址」兩種操作情境。

我們首先參考以太坊上的 WBTC 協議 Lombard - LBTC，Lombard 允許使用者直接連結 Bitcoin 錢包入金，或於未連結 Bitcoin 錢包的狀態下使用外部錢包存入指定地址，這個設計與 Apollo 當前合約升級後的存款體驗相當接近。
Lombard 透過存款地址「外部入金」的流程包含四個主要步驟：
  ① 輸入存入金額 → ② 確認鑄幣服務費 → ③ 確認並生成目標地址 → ④ 手動複製地址進行轉帳。

參考資料 : 確認收款地址

當使用者輸入存款金額後，Lombard 會展示一段完整的鑄幣摘要，清楚列出最終接收地址與目標鏈路，幫助使用者確認操作方向，降低誤操作風險。

參考資料 : 複製存款地址

系統隨即產生一組專屬的 Bitcoin 存款地址，入金後會自動扣除服務費，並在確認完成後跨鏈鑄造為 LBTC，讓整個鑄幣流程透明且可追蹤。

與團隊討論後我們決定採用類似的設計，只是由於業務差異以及當前介面的操作方式，在設計上有一些需要解決的問題：

收款地址需付費建立

為平衡工程端資源成本，我們要求使用者支付開戶費（即創立「存款地址」的費用），而這個收費機制的設計在 DeFi 領域並不
常見，導致部分使用者在尚未鑄幣前就選擇放棄操作，使用者可能會轉向透過其他不需要額外費用的 WBTC 類型鑄幣，而不是選擇需要支付手續費的 zBTC。

缺乏明確的主次引導

我們的介面需要同時呈現「連結 Bitcoin 錢包」與「使用存款地址」兩種方式，兩者皆被團隊視為重要功能，使用者可能無法感受到「存款地址」的便利性，仍然選擇原始鑄幣方式，或是感到困惑不知道該選擇哪個。

團隊希望能讓使用者能快速切換入金方式，因而要求在鑄幣流程最醒目的地方放置入金方式的切換。雖然這樣的設計提升了靈活性，卻也增加了操作複雜度，額外的選項反而削弱了原本鑄幣介面直覺的操作性；但團隊為了搭上行銷活動要求在短期內上線該版本，大幅壓縮設計端探索的時間。

Version 2 的改動除了引發使用者的不確定性外，團隊內部也出現了一些不同聲音。 Co-Founder 認為同時存在兩種入金選項讓介面顯得不直覺，甚至建議直接移除「存款地址」功能。
而這個版本也讓產品設計有了新的挑戰：

我們如何能

① 讓使用者在「連結錢包」與「存款地址」這兩種方式中做出明確選擇，同時保持介面簡潔、易懂

② 更有效地傳達「存款地址」的價值，從而降低使用者在開戶過程中流失的風險

Optimizations

在 Version 2 上線後，我與 PM 及 Growth Team 一起回顧整體體驗，針對「使用者在哪裡感到困惑」與「哪些資訊未被有效傳達」進行分析。由於當時活躍用戶數有限，我透過與 AI 模擬用戶進行啟發式評估（Heuristic Evaluation），推測使用者在操作過程中的潛在情緒與決策節點，並以此作為後續優化方向的依據。

optimization 1

Deposit Address 建立流程

目前問題

缺乏操作預期

使用者在點擊 Create Account 時，無法預測接下來會發生什麼，也不易理解 Deposit Address 就是建立帳戶的結果。這使流程缺乏明確的「前因後果」，增加理解成本。

資訊呈現過度複雜

畫面中包含大量說明文字，資訊層級重疊，使使用者難以快速掃描，也缺乏「下一步該做什麼」的清楚指引，常導致流程中斷。

緒曲線呈現：困惑 → 質疑 → 懷疑

根據模擬評估，使用者在流程中的心理變化如下：
- 困惑：「這個地址是做什麼的？為什麼我需要它？」
- 質疑：「我還沒存款，為什麼要先付費？」
- 懷疑：「不能直接鑄幣嗎？建立地址的價值在哪？」

設計方案

在釐清問題後，我設計了一個三步驟的 Walkthrough Flow，讓使用者在開戶過程中逐步理解 Deposit Address 的意義與

價值。流程分為三個階段：

建立錢包綁定：說明 Apollo 會為使用者開立專屬的 Bitcoin Address，並自動綁定至 Solana 錢包。

跨平台存入：讓使用者理解任何來源（交易所或單鏈錢包）的 BTC，都能直接進行鑄幣。

一次設定，永久使用：清楚呈現「開戶費用」背後的長期價值—地址只需設定一次，後續可永久使用。

視覺輔助傳達概念

透過視覺插圖搭配精簡文字，逐步傳達每個步驟的價值，讓使用者即使不細讀完整文案，也能快速理解 Bitcoin Account 的用途與意義。

自動播放的進度條

每個步驟都會自動播放 5 秒鐘，使用者可以使用畫面上的按鈕來快速的前進、返回上一步驟，或甚至直接跳過這些宣導教程。

完成交易簽署後，系統會立即顯示對應的 Deposit Address，並以 QR Code 形式呈現。
與 Growth Team 討論後，他們認為要用戶付錢創地址的行為可能會引起反感，因而我們將 Deposit Address 改名為「Bitcoin Account Address」，讓用戶認知這是一個開戶行為，而非單純創立地址。

最終，這項優化回答了使用者一個問題：

該如何讓我的 BTC 參與 Solana 上去中心化金融？
使用者現在只需要建立存款地址並存入 BTC 就可以開始在 Solana DeFi 上賺錢。

手機優先的存款地址設計

針對在單一行動裝置上操作的用戶，「下載」功能至關重要。用戶可以儲存 QR Code 圖片，隨後在交易所或錢包轉帳時直接導入，避免單機無法進行
自我掃描，並避免地址複製貼上可能造成的錯誤或焦慮感。

以背景深度強化體驗節點

這個畫面代表用戶首次在 Apollo 上開戶完成，是使用者支付設置費用後的心理轉折點。這裡運用微妙的背景來提升體驗，同時確保 QR Code 仍是主要的視覺焦點。

參考資料

在研究其他金融產品的 Onboarding 設計時，我參考了 Revolut 的做法。Revolut 採用自動播放式（Auto-playing）Walkthrough，以多步驟動畫引導使用者快速理解產品價值與使用情境。每一步都專注於單一重點，搭配具象的視覺主題與簡短標題，幫助使用者在數秒內抓到概念，同時降低學習負擔。

結果

這次的優化為 Apollo 帶來幾個定位、體驗上的的改善：

強化開戶後的即時回饋

在過去的流程中，使用者在完成開戶後會直接回到 Apollo 的操作介面，但由於缺乏明確的反饋，他們往往感受不到這筆費用帶來的實際價值。在這次優化中，我重新設計了開戶完成後的體驗—系統會立即顯示使用者專屬的 Deposit Address，並以 QR Code 的形式呈現。這樣的設計讓使用者能明確感受到「我擁有了一個新的地址」，並提升開戶行為的價值感。同時，這個 QR Code 也能被直接掃描或儲存，無論是透過中心化交易所（CEX）還是單鏈錢包，使用者都能馬上存入 BTC 並完成鑄幣。

擴大可觸及用戶群

許多散戶習慣使用交易所或在交易所中 DCA（定期定額）購入 BTC，這項設計能幫助 Apollo 觸及更多原本無法參與 zBTC 生態的 BTC 持有者，拓展整體用戶群。

對標中心化競品鑄幣體驗

在過去，Apollo 的鑄幣流程僅能透過介面操作完成，不利於吸引首次接觸 DeFi 的用戶。而 Coinbase 推出的 cbBTC 採用截然不同的做法：使用者只需將 BTC 存入指定地址，即可自動完成鑄幣。這種「像匯款一樣簡單」的設計降低了進入門檻，讓鑄幣流程更貼近傳統金融產品的心智模型。

在這次優化中，我參考了這樣的邏輯，將「Deposit Address」從技術設定轉化為核心互動節點。使用者在開戶後即可獲得專屬地址，未來僅需將 BTC 存入該地址，即可自動完成鑄幣。這次的改動提升了 Deposit Address 在 Apollo 產品中的存在感，也讓整體鑄幣流程能貼近競品的鑄幣體驗。

optimization 2

鑄幣流程

目前問題

缺乏操作預期

介面同時呈現兩種存入方式，但沒有說明差異，使用者不確定該選哪一個；而 Deposit Address 流程重複出現試算畫面，也進一步造成混淆。

Deposit Address (Bitcoin Account) 定位不明確

使用者無法理解 Deposit Address 在整個鑄幣流程中的角色，不清楚為什麼需要先建立地址，導致心智模型斷裂。

缺乏關鍵環節的操作引導

操作流程中斷點多，但缺乏明確提示，使用者也不知道鑄幣流程可能需要長達 30 分鐘，因此容易提前放棄。

信任指標不足

介面缺少 TVL 數據、zBTC 相關生態系等能建立認同與安全感的訊息，降低了整體產品可信度。

緒曲線呈現：困惑 → 試探 → 誤解

透過內部討論與啟發式評估，我們歸納出常見的情緒變化：

困惑：「兩個入金方式差在哪？」
試探：「我現在應該選哪一步？」
誤解：「跳出地址了？流程是不是壞了？」

Solution 1
簡化鑄幣介面

這次優化的核心在於降低操作決策負擔並重整層級結構，我將主要操作焦點集中於 Connect Bitcoin Wallet，
同時降低 Deposit Address 在鑄幣介面中的權重，僅以輔助性的 QR Code 按鈕呈現，已建立地址的使用者能快速取用，
而不干擾主流程。這是因為在建立 Bitcoin Account 的過程中，使用者已充分理解其價值與用法，鑄幣介面只需提供快速取用的入口即可。

另外，我重新設計輸入框的資訊層級，簡化輸入框線條結構並加入跨鏈資訊（Deposit from Bitcoin / Receive on Solana），讓使用者在認知上明確感受這是一個跨鏈鑄幣行為而非單鏈 Swap 操作。內部測試後團隊一致認同優化後的介面在流程清晰度、決策效率上都有顯著的改進。

前一版設計

更多線條包覆輸入框，視覺重點看起來是整個區塊

介面簡化後

減少線條並降低線條的透明度，讓視覺重點聚焦在數字上

Solution 2
解決手機端錢包的鑄幣操作瓶頸

為了解決過往手機版用戶無法操作 Apollo 鑄幣的問題，我在手機版本上對按鈕擺放順序做了微調

在手機版上主要顯示「Display Bitcoin Account」的

QR Code 按鈕，而非連結 Bitcoin 錢包

這是因為大部分 BTC 持有者不會選擇將 BTC 放在跨鏈錢包 Phantom 裡，在手機版上優先顯示快速取用 Bitcoin Account 按鈕可以讓使用者無需連結錢包，即可透過其他 Bitcoin 錢包或中心化交易所直接轉入 BTC 並完成鑄幣，成功打開行動端的使用場景，並維持跨平台體驗的一致性。

Solution 3
強化 Bitcoin Account 在 Apollo 中的定位

在過去的設計中，Bitcoin Account 雖然是鑄幣流程的關鍵節點，但在整體產品架構中卻缺乏明確的定位。使用者往往只能在開戶流程或特定介面中短暫看到這組地址，卻無法在 Apollo 中自然地找到它，這不僅造成操作阻力，也削弱了其作為跨鏈互動入口的產品價值。在這次優化中，我從產品架構重新檢視 Bitcoin Account 的角色，並將其從「技術性設定」提升為「帳戶系統的一部分」。我將 Bitcoin Account 與使用者的 Solana 錢包地址放在同一層級，讓使用者能在任何時候快速取得。

這樣的調整不僅重新建立了 Bitcoin Account 的產品定位，也讓使用者能自然理解：「這是一個我在 Apollo 的專屬身份，我可以用任何錢包或交易所透過它與 Apollo 進行互動。」

從產品策略角度來看，這項改動能降低使用者對 walkthrough 的依賴、提升鑄幣流程的可回訪性，並讓跨鏈存入行為成為一種、「隨時可觸發」的核心能力，而不是流程中的偶發事件。

Solution 4

增加鑄幣後的即時回饋感

在優化後的流程中，我重新檢視了 Apollo 原本的「交易成功」回饋方式，發現現行設計容易造成誤導：Solana 端的交易成功並不代表整個鑄幣已完成，但 toast 呈現方式卻讓使用者誤以為流程已結束，同時真正的重要進度資訊被放在頁面下方，需要滑動才看得到。

因此我將 Successful Toast 改版為完整的通知系統（Notification System）：

在介面右上角即時呈現正在進行的跨鏈交易（包含存款與提款）。
清楚說明每個階段的正在進行處理（例如 Verify 階段代表正在確認 Bitcoin 鏈上存款是否到帳）。
提供 ZeusScan 連結（Zeus 的跨鏈交易 Explorer），使用者能直接查看 On-chain 詳細進度。

Result & Takeaway

這次的流程優化並未直接帶動 zBTC 鑄造量的成長。主要原因在於使用者行為與產品定位本身的限制：首先，多數 BTC 持有者以長期持有為主，本身就缺乏主動操作的動機；對於尚未成熟、缺乏擔保機制的新型去中心化產品，他們也較難建立信任。其次，zBTC 作為封裝資產，本質上屬於金融商品，其採用度依賴明確的應用場景與收益模型。然而 zBTC 的推出偏向技術導向，在市場、應用與獎勵設計不足的情況下，即使 Apollo 的流程再流暢，仍難以大幅刺激需求。

在市場研究後也更清楚地意識到：「Apollo 的設計限制了資金流入的來源。」

目前使用者只能以 BTC 鑄造 zBTC，缺乏多幣種導流機制。例如多數 DeFi 使用者主要持有 USDC/USDT 用於操作，但這些穩定幣無法直接鑄造 zBTC，只能透過 Swap 購買市場上既有的 zBTC 流動性，使整體生態難以擴張。若從產品策略角度重新審視，團隊應該思考如何讓更多幣種成為 zBTC 的入口，例如「USDC → 自動購買 BTC → 自動鑄造 zBTC」的產品路徑，就像交易所定投或跨鏈聚合器的做法。這類設計能夠從更廣的使用人群中導入新資金，而不是被動依賴原生 BTC 持有者或機構投入，從而突破 zBTC 生態受限於單一路徑的成長瓶頸。

中文