Skip to main content

自己做一個 PERP 交易所 APP

Opass
Opass
A life well lived

前情提要​

這是我在 2025 年 9 ~ 12 月的專案，我花了 86 天完成了一個交易所的 App 並上架到 Google Play Store，包含中間去旅遊2個禮拜。

2025年，Perpetual Procol 面臨了很大的壓力，探索了幾個月但找不到明確可行的產品方向，我們嘗試做了一個跨鏈的現貨交易所 Nekodex，但一直找不到 Product Market Fit，用戶數量上不去。

同時維護 Nekodex 也成為負擔。Nekodex 的目標用戶是那些不熟悉幣圈的新手用戶，為了讓這些用戶不用理解 Gas 的概念也能使用，我們使用了 AA Wallet 當作底層基礎建設。但實務上發現維護是個大坑，每個用戶在鏈上都有一個合約錢包，每次遇到合約需要升級，永遠都會有一部分的用戶還停留在最舊的版本。最近一次是2025 9月的時候，ZeroDev 回報說他們的 AA Wallet 合約有個漏洞需要升級才能繼續使用，我們花了將近一週才搞定這件事。

因此在2025年9月，我們決定先做一個更好維護的 PERP 交易 APP，並計畫之後下架 Nekodex，將用戶轉移到新的產品上，以減輕維護負擔，保留精力探索其他產品方向，這個產品叫做 PERP GO，一個 mobile 的 perp 交易 app。

但 12 月時，公司決定將 Perpetual Protocol 出售移交給另一個團隊。和老闆討論後，我們決定開源這個專案，身為 PERP GO 主要的開發者，我會在這篇文章分享開發與當時的決策細節。

整個 PERP GO App 的程式碼都已經 Open Source 放置在 github 並採用 CC 4.0 授權，您在移除 PERP GO 商標後可以自由使用。

PERP GO Demo

怎麼決定背後的技術選型？​

PERP GO 的目標是減少維護成本。因此直接以當前 PERP defi 市占率前最大的 Hyperliquid 當做後端，會是最簡單的。

深入研究會發現，Hyperliquid 官方只維護前端和後端 API，但 Hyperliquid 本身並沒有跳下去做 mobile App，反而是在官方網站推薦了其他 App 的前端。

CleanShot_2026-02-01_at_15.03.112x.png

我們下載並研究了所有競品，最後的結論是：透過 Hyperliquid 官方提供的分潤機制可能是有利可圖的。

Builder Code 是 Hyperliquid 官方提供的分潤機制，開發者透過打造一個 Hyperliquid 前端介面來吸引用戶，如果使用者透過該前端介面下單，那開發者可以獲得分潤，最高可以拿到用戶交易金額的 0.1%。

最關鍵的數據是 Hyperliquid BuilderCode 的收益，DUNE 上可以查到當前常見最賺錢的 BuilderCode 有哪些，其中最賺錢的是黃色的 phantom 和粉紅色的 based(大約一天有4~5萬美金的收入)。

CleanShot_2026-02-01_at_15.25.002x.png

產品定位​

一開始我們想，有沒有辦法引流平時會用 Hyperliquid 網頁版本的用戶？

Hyperliquid 官方網站上，有一個 Link Mobile Device 的按鈕，會提供一個 QR Code，允許用戶用手機打開 Hyperliquid 來交易。

CleanShot_2026-02-01_at_15.43.042x.png

是否有辦法做一個手機 App 來，直接掃描該 QR Code，我們就直接把該用戶綁定到我們的 PERP GO app 內呢？

結論是不行，不是技術上不行，而是商業上缺乏價值。

Hyperliquid 之所以能做到不用每次交易都簽名，是因為使用者在登入後，會授權另一個 Agent Wallet 代為操作用戶的資產。這個 Agent Wallet 可以下單，但不能存款與提款。

最重要的是：直接透過這個 Agent Wallet 下單，Builder 是沒辦法抽手續費的。

用戶必須用主要的錢包(master wallet)授權前端介面能夠抽手續費，最高不超過 0.1 %，前端交易介面才能夠在每次交易時，攜帶一個 builder code 到 Hyperliquid 後端 API，成交時抽 Builder Fee。

所以如果你研究了競品(based app, dexari, lootbase)會發現，所有的競品都在鼓勵用戶「在 app 上建立錢包」，原因是 app 上自建錢包就能夠替用戶簽 approve Builder Fee。

因此最終所有 hyperliquid 前端 app 會導向三種註冊方式的選擇

  • 幫用戶產生 seed phrase 並保存在手機上、或是允許用戶匯入 seed phrase
  • 讓用戶能夠用 email 註冊一個對應的錢包(使用 privy 或是 turnkey 之類的服務)
  • 讓用戶能夠掃 Hyperliquid 官方 QR Code 但是賺不到錢

而我在訂定 PERP GO 規格時，考量到幫用戶產生 seed phrase 會有很高的資安風險，最終選擇是

  • 對於初階用戶，使用 email 可以註冊一個錢包
  • 對於進階用戶，可以使用 mobile wallet app 直接進行跨 App 的簽名授權與交易。

這麼一來，就可以保證交易過程都是自託管的(self-custody)，用戶永遠擁有錢包的控制權，我也不用承擔幫用戶保管 private key 的風險。另外因為知道用戶的 master wallet，所以用戶在使用前，可以請求用戶給予 Builder Fee 的授權。

技術選型與坑​

  • Mobile App Framework
    • Expo，React Native Based 的跨平台 App 開發框架，能夠同時開發 iOS 與 Android App 並獲得近似原生的體驗，另外提供 Expo Update 能進行 Live update，小升級的情況下用戶不用重新到 App Store 重新安裝套件。
  • TypeScript Hyperliquid SDK
    • Hyperliquid 有兩個非官方的 SDK，@nktkas/hyperliquid 和 @nomeida/hyperliquid
    • 雖然乍看之下，@nomeida/hyperliquid 的設計比較漂亮，但最終我會選擇使用 @nktkas/hyperliquid 。原因是 @nomeida/hyperliquid 只提供了透過 private key 來初始化 SDK 的方法。但能夠不碰到用戶的 private key 會是更好的選擇。而 @nktkas/hyperliquid 能夠提供了 viem 相容的 account 來初始化 SDK，這代表我們可以在不用知道用戶 private key 請用戶簽名授權與送出交易。
    • 實務上，還是會遇到 @nktkas/hyperliquid 的一些內部設計問題，要記得刻意不使用某些 SDK 提供的功能。像是盡量不要使用 SymbolConverter，原因是雖然這個 helper method 方便，但其背後的實作是打另外一個 API 來取得當前的 Symbol，這個另外打的 API 會成為 Rate Limit 的破口，讓你沒辦法很好的掌握 API Rate Limit，另外你也很難確定 Symbol Converter 背後有沒有對市場做快取。
  • privy
    • 優點
      • 提供用戶能夠透過 email 註冊帳號，由 privy 幫你保管 private key。此外具備了讓用戶能夠自行匯出 private key 的功能，出問題時用戶可以自行逃生。
      • Stripe 已經在2025年6月收購了 privy，是個相對值得信任的服務。
    • 坑
      • privy 的 react-native-SDK 功能相對原始，由 privy SDK 提供 UI 套件，並沒有提供太多能夠自訂的空間。
      • 我會選擇使用原生的 EOA 錢包，而不是 AA Wallet，讓用戶自己處理 gas 問題，保持簡單。選 AA Wallet 幫用戶代付 gas 會有 PTSD。
  • reown/appkit
    • 優點
      • reown 背後是原本的 wallet connect。reown/appkit 的好處是能夠選擇手機上的其他 mobile wallet 來連接到我們的 app 上，需要簽名時，再跳轉到對應的 wallet app。
      • 支援大部分的 mobile wallet。
    • 坑
      • wallet connect 普遍的問題是，用一陣子後可能會遺失連線需要重連。或是 Mobile Wallet App 在需要簽名的時候一直沒有反應。背後原因可能是太多連線跳轉和狀態管理。通常把 Mobile Wallet App 強制斷線重開就會正常。但在我們的使用場景下，因為大多數的交易都是授權給 Agent Wallet 做操作，所以不算是大問題。
      • 沒辦法使用 metamask，不知道為什麼 metamask 就是連不上。
  • charting_library
    • 坑
      • 目前市面上，你常常在交易所看到那些好看的 Charting Library 是 Trading View 的 Advanced Chart，是需要用公司的名義和 Trading View 聯繫簽署申請授權才能拿到 Source Code。Trading View 會檢視公司是誰、要用在哪裡，如果惡意使用會求償。我當時申請授權是免費的
      • 因此如果你仔細看一些其他交易所的 Trading Chart，會發現很多交易所其實都是自己開發自己的版本。大概是因為不想被綁定在 Trading View 的緣故吧。
      • 就算你用了 Advanced Chart，你會發現你依然沒辦法實作出很多交易所會看到的「拖曳設定Limit Order 或是止盈止損」，因為這功能被 v28.0.0 的 Trading View Advanced Chart 鎖住當作進階功能了
      • 如果申請不到授權，那免費的選擇會是使用 Trading View 的 Open Source 版本 LightWeight Charts。但就頗陽春，很多沒有任何技術指標。

開發策略​

我在實作 App 時，把相對內聚自然聚合成一個 contexts。

├── contexts/              # Core business logic (Hexagonal Architecture)
│   ├── agent/             # Agent wallet management
│   ├── bridge/            # Cross-chain bridging
│   ├── builderFee/        # Builder fee management
│   ├── history/           # Trade history
│   ├── margin/            # Margin & leverage
│   ├── market/            # Market data
│   ├── order/             # Order management
│   ├── position/          # Position management
│   ├── referral/          # Referral system
│   └── telemetry/         # Error tracking & analytics
  • contexts
    • agent 一個主帳號允許最多 3個 named agent + 1 個 unnamed agent
    • bridge：用戶 deposit / withdraw collateral 的本質就是把錢 bridge in/out hyperliquid。
    • builderFee：管理用戶是否已經授權 builder fee，有授權才能夠抽成
    • history：顯示交易歷史記錄
    • margin：設定每個市場的 margin mode、槓桿倍數
    • market：列出所有當前的市場
    • order：管理下單功能（有很多種不同的 Order）
    • position：管理用戶當前的倉位
    • referral：管理用戶是否設定了推薦碼
    • telemetry：追蹤用戶的操作行為分析

為什麼要拆解出這麼多 Context?

原因是: 交易所並不是一個隨隨便便就可以 Vibe Coding 出來的東西。完全放飛 Claude Code 自己開發，肯定會在某個時間點就陷入複雜度地獄。

最大的問題有三個

  1. 交易所的功能繁雜
  2. UI 行為難以驗證
  3. 很多問題是一邊做一邊探索才會浮現

功能繁雜​

舉例來說，下單最主要有下列2種 Order

  1. Market Order
  2. Limit Order

搭配下列兩種變化

  1. Reduce Only：只允許減倉
  2. TP/SL：允許設定止盈、止損

你很容易就可以想到有下列問題需要測試

  1. 如果一個 Limit Order 勾選 Reduce Only，他是參考 Limit Order 時的 Position 還是 Limit Order 本身觸發時的 Position?
  2. TP/SL 也要可以設定 Limit Order 和 Market Order
  3. TP/SL 的觸發是 partial 成交就觸發，還是要完整成交才會觸發？
  4. 如果 parent 訂單取消了，那麼 TP/SL 訂單是否會跟著取消？

如果不加以管理，很快這些問題就會淹沒你的大腦，這還只是下單而已。

UI 難以測試​

UI 測試一直都是個麻煩的問題。理想上當然可以使用類似 react-native-testing-library 的測試框架來模擬 react render 的結果。但對於一開始連 UI 要長什麼樣子都不確定的應用來說，這種測試方式只是確定「有 render 出你要的內容」，但並不能保證排版是你要的。

我有嘗試過使用 mobile mcp，想辦法讓 claude code 能夠在開發時，自行擷取手機畫面/或是取得 react-native DOM Tree來驗證結果。我會說效果差強人意。最主要的問題是「操作」到「看到結果」會有個時間差，基於截圖的測試難以檢查 pop up 之類的動畫，另外你也很難透過截圖來確認下單結果。

甚至最麻煩的是，很多時候，你一開始根本不確定要 UI 做成什麼樣子。

這種情況下，我會選擇先直接參考其他 App 是怎麼做的。例如打開 Based App，看看他們是怎麼處理各種下單的狀況、或是怎麼顯示不同精度的 OrderBook。

關注點分離​

用一句話來說的話，在近三個月與 AI agent 一起 coding 的旅程，我認為最好的策略是關注點分離。

盡可能把問題縮小到一個足夠內聚的邊界，在修改時不會改壞其他東西。

我主要關心兩件事

  • 我希望能夠在問題規模變大時，依然能夠知道要改哪裡
  • 我希望功能之間盡可能的切乾淨，這代表我可以在同一時間做更多不相干的功能，而不會彼此打架。

因此我選擇把架構設計 UI 和業務邏輯分離。

App 的 UI 有自己的目錄，UI 怎麼改都只侷限在 UI 的目錄中。這可以有效減少和設計師協作時的 merge conflict，設計師在怎麼改，都只會在 UI 的目錄中調整編輯，UI 不影響功能。

至於業務邏輯，就按照功能進行切分，讓業務邏輯盡量與 UI 無關，這樣 AI agent 才方便驗證。功能太多的話，就按照當下的感受來切分 contexts，反正怎麼切是沒有標準答案的，更像是一種基於開發者直覺的藝術。這些 context 也會邊做邊調整，有可能做一做發現某些能應該獨立成一個新的功能類別、或是應該把兩個功能類別合併成一個。最主要的目標還是，讓開發者可以清楚的知道當前已經實作了哪些功能。

最後就是透過老方法：相依注入，把業務邏輯注入回 UI 入口中。

如果你想了解更具體實作，可以參考我的 六角架構開發規範

開發 Trading App 會遇到的 Domain 與非 Domain 知識​

你需要掌握的 Hyperliquid Domain Knowledge

  • 不同市場下，精度的計算方式(szDecimals)
  • Deposit Withdraw 會在 Arbitrum 上進行 bridge，withdraw 會收走 1U 手續費。
  • 所有下單的行為(Market Order, Limit Order, Reduce Only, TP/SL Order)
  • API 是有權重的 Rate Limit
  • 每個市場可以設定獨立的保證金模式(Isolated, Cross)和最大的槓桿倍數
  • fee 的計算公式（Fee, Builder Fee, Referral Discount 與 Maker/Taker Fee 的差異）
  • 如果想要支援美股代幣化的市場 HIP-3，要記得開啟 dex abstraction，並且留意有些市場的交易對並不是 USDC。

除了 Hyperliquid Domain 外，我認為設計一個好的 CI 開發流程也很重要。

  • Expo 怎麼管理 env？
    • 我的建議是直接使用 Expo dashboard 管理 env，需要理解不同寫法的環境變數何時會生效。例如有的是在 build time 看得見，有的是在 runtime 才看得見。
    • 你可以參考我的 管理環境變數的規範
  • 如何管理 App 的版本號，什麼時候該升版？
    • 這是個討人厭的問題。必須先理解App 的更新方式有兩種，一種是可以直接 in-app 內升級，另一種是需要進到 App Store 重新安裝新版的 app。你會希望盡可能減少要進 App Store 升級，因為每次 App 升級就會需要重新 Apple 送審，耗時冗長 。如果是 OTA(Over-the-air) 升級就可以不用通過送審。但你又不可能完全只依賴 OTA 升級，總有一天你可能會需要 App Store Upgrade
    • 您可以參考 我的版本號的更新規範

上架會遇到的問題​

開發之外，最困難的卡點應該會是上架。

容易解決的麻煩：

  • 要提供 iOS, Android 在不同裝置(手機、平板)上的操作截圖，這部份可以靠安裝 iOS/Android 的虛擬機解決
  • 填寫一大堆隱私權與資料使用的許可

難以解決的麻煩：

一開始一切都還算順利，Android Play Store 已經順利上架。而 App Store 要求一些 UX 上的改進。但沒想到 App Store 後來突然要求「需要當地政府的許可證明」，否則就不予上架。

我們決定先嘗試只在塞席爾上架。因為塞席爾對於虛擬貨幣業的規範是，沒有代為保管用戶資產的話，就不受虛擬貨幣交易法案 VASP 的監管限制。這個 App 完全使用自託管的方式運營，理應是符合規範的。但儘管對 App Store 進行解釋，App Store 依然進入了鬼打牆的狀態，沒有明確的政府文件允許，就是不許上架。

我記得 2026 年 1月之後，Android Play Store 也對於加密貨幣交易所相關的 App 進行更嚴格的限制。當然不公開上架，在自己手機上進行內測是沒問題的。如果有意圖公開上架記得先想辦法取得 App Store 同意。

結語​

在此記錄並分享了過去三個月製作一個 Mobile Trading App 所有遇到的困難、踩過的坑，如果你曾經想自己做一個交易所 App，希望這篇文章可以讓你知道前方的道路是什麼樣子。