整理加密市場資料有一種很熟悉的痛苦。
你週一下載 ETH 收入，週二複製 Solana 交易量，週三再把 ETF 流入貼進試算表。等到月底準備更新報告，才發現其中一個網站改了欄位名稱，另一個資料源補回了三天前的數字，原本看起來很完整的儀表板，瞬間變成沒有人敢動的 Excel 古蹟。
Blockworks Data API 想解決的，正是這種「資料明明公開，整理起來卻像在拼失散多年的族譜」的問題。
它讓使用者透過程式直接取得 Blockworks Research 使用的鏈上指標、資產資料與圖表底層數據，接進 Python、Excel、BI 儀表板、排程工作或內部分析工具。
但我想先把期待調整到正確位置：API 解決的是資料存取與標準化，不會自動替你產生正確的投資結論。
我做數據分析時最怕的，不是 API 回傳錯誤，而是它每天都穩定回傳一個你誤解的數字。前者很快會被發現，後者可能安靜地躺在儀表板裡半年，直到有人根據它做了一個很貴的決策。
Blockworks Data API 是什麼？
Blockworks Data API 是一套以 REST API 形式提供的加密市場數據服務，主要輸出已經過整理的資產資料、鏈上指標、ETF、企業加密資產儲備及研究圖表資料。
按照 Blockworks 的說法，API 連接的是其研究平台使用的資料倉庫，資料已經經過索引、指標設計、清理與驗證，可以直接接入模型、儀表板及自動化報告。Blockworks API 官方介紹
目前官方支援清單約涵蓋305個項目，其中包括：
- 29條區塊鏈
- 136個DeFi協議與加密應用
- 97個ETF或相關資產管理產品
- 43家加密資產儲備公司
實際數量仍會隨官方新增項目而改變，最新狀態應以 Blockworks Projects Supported 頁面為準。
它不是區塊鏈節點 API
Blockworks Data API 與 Ethereum RPC、Solana RPC 或區塊瀏覽器 API 的用途不同。
節點 API 比較適合查詢：
- 某一筆交易是否成功
- 某個地址的資產餘額
- 特定區塊內容
- 智能合約事件
- 即時鏈上狀態
Blockworks Data API 則比較適合取得：
- 每日活躍地址
- 每日交易筆數
- 網路手續費與收入
- 穩定幣供應量
- DEX交易量
- 質押比率與收益
- ETF資產規模與流量
- 企業加密資產儲備
- 協議存款、借款與收入
簡單來說，節點 API 給你原始零件；Blockworks Data API 比較像已經整理好的分析材料。
它也不是高頻行情 API
Blockworks 的鏈上指標多數採用日頻資料，適合基本面追蹤、研究報告、週報、回測與長期監控，但不適合直接拿來做秒級或分鐘級交易。
如果策略需要即時成交價、訂單簿深度、資金費率或逐筆成交資料，仍應使用交易所 WebSocket 或專業市場行情服務。
把日頻鏈上資料接進高頻策略，就像拿每月財報判斷下一分鐘股價。資料本身沒有錯，只是時間尺度完全不對。
Blockworks API 可以取得哪些資料？
Blockworks API 目前大致分成資產、指標、圖表、市場統計及代幣透明度幾個層級。
資產資料：價格、市值、供應量與 OHLCV
Assets 相關端點可以取得加密資產基本資訊，並透過獨立端點或 expand 參數展開：
- 即時或最新價格
- 市值
- 流通與總供應量
- 市場交易資訊
- OHLCV價格資料
- Sparkline簡易走勢
這一層比較適合建立資產清單、價格看板或投資組合監控。
不過價格資料與鏈上基本面最好分開保存。如果把價格、市值、收入與活躍地址全部塞進同一張寬表，之後只要其中一個來源改版，整條資料管道就可能一起壞掉。
鏈上指標：API 最有價值的部分
Metrics 是 Blockworks Data API 的核心。
官方將指標整理成具有固定 identifier 的時間序列，例如：
- active-address-total：活躍地址
- transaction-total：交易總數
- transaction-fee-total-usd：美元計價手續費
- rev-usd：美元計價 REV
- stablecoin-supply-total-usd：穩定幣供應量
- dex-spot-volume：DEX現貨交易量
- staking-rate：質押比例
- lending-tvl：借貸協議TVL
指標資料通常包含名稱、說明、資料來源、頻率、幣別、資料型別、聚合方式及最後更新時間。Blockworks Metrics Catalog
這些 metadata 不是可有可無的附註。
例如，同樣是收入，Revenue、REV、Application Revenue 與 Trading Revenue 可能代表不同經濟活動；同樣是每日數字，SUM 與 LAST 的意義也完全不同。
在把指標放進模型前，我一定先確認三件事：
- 這個數字到底在衡量什麼？
- 它用SUM、AVERAGE還是LAST聚合？
- 單位是美元、原生代幣、比例還是筆數？
如果這三件事沒有確認，後面的機器學習只是在高速處理語意錯誤。
圖表資料：直接取得研究圖表的底層數字
Blockworks API 也提供 Charts 端點。
使用者可以先透過 /v1/charts 搜尋圖表，再使用圖表 ID 取得底層資料。目前官方文件範例顯示，可搜尋的圖表數量超過3,200張，內容包括：
- BTC與ETH區塊補貼
- L1使用狀況
- ETH質押收益
- MEV小費
- Arbitrum交易費用
- 協議收入與競爭比較
API 支援分頁、搜尋、排序與條件篩選，適合把研究平台上的既有圖表接進內部儀表板。Blockworks List Charts、Get Chart Data
這項功能對研究團隊很實用，因為不必重新撰寫每張圖的計算邏輯。
但我會保留圖表 ID、圖表名稱與擷取日期，而不是只保存數值。否則半年後看到一欄 btc_profit，你可能已經不記得它是礦工毛利、網路收入，還是某張圖自行計算的衍生指標。
ETF 與企業儲備資料
Blockworks 的支援項目還包括全球加密ETF及企業加密資產儲備。
可用資料涵蓋：
- ETF每日資金流
- ETF資產管理規模
- 30日滾動資金流
- 不同產品的市場占比
- 企業持有BTC、ETH、SOL等資產的數量
- 企業加密資產NAV
- 股票市值相對加密資產NAV的倍數
- 流通股數與企業價值
這一組資料適合研究ETF需求、企業財庫溢價，以及加密資產如何透過傳統證券市場傳遞。
我不會只因某家公司增持BTC就判定市場看多。還要一起看它是用現金、可轉債還是增發股票融資，以及公司相對資產淨值的溢價是否已經過高。
API 可以把資料送到你面前，但風險判斷還是需要人做。
如何取得 Blockworks API Key？
使用者需要先登入 Blockworks Research 帳戶，進入 Account Management，再到 API 頁面建立金鑰。
所有請求都必須在HTTP Header中加入：
x-api-key: YOUR_API_KEYAPI 的基礎網址為：
https://api.blockworks.com如果沒有提供金鑰或金鑰失效，通常會收到401 Unauthorized；如果帳戶方案沒有相應權限，則可能收到403 Forbidden。Blockworks API Authentication
官方文件仍保留分階段開放的說明，因此不同帳戶能取得的端點與資料範圍可能不完全相同。即使成功建立金鑰，也應實際測試需要的資產與指標是否包含在目前方案中。
不要把 API Key 寫進程式碼
最常見的錯誤是直接把金鑰貼進 Python 檔案，再把整個專案上傳到 GitHub。
即使後來把那一行刪除，金鑰仍可能留在 Git 歷史紀錄中。
比較安全的方式是存入環境變數：
BLOCKWORKS_API_KEY=你的金鑰程式執行時再讀取：
import os
api_key = os.environ["BLOCKWORKS_API_KEY"]正式環境則可以放在AWS Secrets Manager、Google Secret Manager、1Password或CI/CD的秘密變數中。
官方也建議開發、測試與正式環境使用不同金鑰，並定期輪替。如果某個服務出現異常請求，才不需要一次撤銷所有系統的權限。
Blockworks API 的使用額度是多少？
官方文件目前顯示，Standard Blockworks Research方案每月包含2,500次API請求，而且是以團隊為單位計算。
也就是說：
- 同一團隊建立多組API Key，不會增加總額度
- 團隊內不同成員的請求會合併計算
- 超過2,500次後，需要聯絡銷售或支援團隊
- 專用API方案的正式價格仍可能調整
完整規則可查看 Blockworks Usage & Rate Limits。
2,500次看起來不少，但如果每五分鐘抓一次資料，一個端點一個月就會使用超過8,000次。
由於多數鏈上指標是每日更新，通常沒有必要每分鐘輪詢。對我來說，比較合理的做法是每天固定抓取一至兩次，並將結果存進自己的資料庫。
另外，部分端點允許一次查詢多個項目。例如同一個收入指標，可以在一個請求中同時取得Ethereum、Arbitrum與Optimism資料，這比為每條鏈各打一個API請求節省很多額度。
使用 Python 取得 Blockworks 鏈上數據
一個比較實際的流程，不是直接猜指標名稱，而是先查詢指標目錄。
第一步：搜尋可用指標
import os
import requests
API_KEY = os.environ["BLOCKWORKS_API_KEY"]
response = requests.get(
"https://api.blockworks.com/v1/metrics",
headers={"x-api-key": API_KEY},
params={
"project": "ethereum",
"limit": 100
},
timeout=30
)
response.raise_for_status()
metrics = response.json()
for metric in metrics["data"]:
print(
metric["identifier"],
metric["name"],
metric["interval"],
metric["denomination"]
)這段程式的目的不是取得指標數值，而是確認官方使用的identifier與資料定義。
Blockworks 官方也建議先使用List Metrics端點尋找穩定的指標識別碼，再呼叫單一指標資料。Blockworks List Metrics
第二步：取得多條鏈的時間序列
假設我們想比較Ethereum、Solana與Base的美元計價REV：
import os
import requests
import pandas as pd
API_KEY = os.environ["BLOCKWORKS_API_KEY"]
response = requests.get(
"https://api.blockworks.com/v1/metrics/rev-usd",
headers={"x-api-key": API_KEY},
params={
"project": "ethereum,solana,base",
"start_date": "2026-01-01",
"end_date": "2026-08-20"
},
timeout=30
)
response.raise_for_status()
payload = response.json()
frames = []
for project, rows in payload.items():
frame = pd.DataFrame(rows)
frame["project"] = project
frames.append(frame)
data = pd.concat(frames, ignore_index=True)
data["date"] = pd.to_datetime(data["date"], utc=True)
data["value"] = pd.to_numeric(data["value"], errors="coerce")
print(data.tail())Blockworks 的時間序列回應通常以項目名稱作為第一層Key，每個項目底下再放置date與value。Blockworks Get Single Metric
這種結構對單一指標很清楚，但如果你要同時處理二十個指標，最好先轉換成自己的標準格式：
date | project | metric | value | unit | source | pulled_at否則每個API回應都使用不同寬度的資料表，後面會很難維護。
從 API 到儀表板：完整數據管道怎麼設計？
真正穩定的系統不會讓儀表板直接呼叫外部API。
如果每次開啟頁面才即時向Blockworks請求資料，使用者一多，很快就會消耗額度；外部服務短暫異常時，整個儀表板也會一起壞掉。
比較可靠的架構可以拆成六層。
第一層：排程抓取
使用GitHub Actions、Airflow、Prefect、n8n或雲端排程器，每天固定呼叫API。
日頻資料通常一天更新一至兩次就夠了。除非官方明確標示更高頻率，否則不需要把抓取間隔設成五分鐘。
第二層：保留原始回應
API回傳的JSON不要立刻覆蓋。
我會保存：
- 請求網址
- 查詢參數
- 擷取時間
- HTTP狀態
- API回應內容
- 指標identifier
- 專案slug
這樣資料出現異常時，才能確認是來源修正、轉換程式錯誤，還是分析模型出了問題。
第三層：資料驗證
進入正式資料庫前，至少檢查：
- 日期是否重複
- value是否為空值
- 單位是否突然改變
- 最新日期是否落後
- 數值是否超出合理範圍
- 歷史資料是否被大幅修正
API資料仍可能因延遲事件、重新索引或方法更新而修訂。官方部分指標文件也明確提醒，日頻資料可能在延遲資料抵達後更新。
因此，我通常不只抓昨天，而是每天重新抓取最近三至七天，再使用date、project及metric作為唯一鍵進行upsert。
第四層：標準化與衍生指標
原始資料清理後，再計算：
- 7日與30日變化率
- 7日移動平均
- 30日Z-score
- 收入相對市值
- 手續費相對交易量
- 穩定幣供應成長率
- 活躍地址相對交易量
- ETF流入相對資產規模
這些衍生指標應由程式確定性計算，不要交給語言模型心算。
第五層：儲存與視覺化
資料量不大時，PostgreSQL或BigQuery已經足夠。個人研究也可以先使用DuckDB與Parquet，不一定要一開始就建立昂貴的雲端架構。
Power BI、Tableau、Looker Studio、Metabase或內部網站，都應讀取自己的資料庫，而不是直接連向外部API。
第六層：AI 解讀與警報
最後才輪到AI。
AI可以讀取已經整理好的異常指標、統計摘要與事件資料，產出週報、風險提示或待研究清單。
這個順序不能倒過來。先讓AI自己決定抓什麼、怎麼算、該相信哪個欄位，結果通常很有創意，但不一定很有用。
如何把 Blockworks 資料接進 AI 智能分析？
我比較推薦「程式負責計算，AI負責解釋」的分工。
例如系統每天取得ETH的REV、穩定幣供應、活躍地址與ETF流量後，先由Python計算：
- REV七日平均下降18%
- 穩定幣供應七日增加2.4%
- 活躍地址與30日平均相近
- ETF連續三日淨流入
再把這些結構化結果交給AI，要求它回答：
- 哪些指標方向一致？
- 哪些指標出現背離？
- 可能有哪些合理解釋？
- 還缺少哪些資料才能驗證？
- 哪些結論目前不能成立？
這比直接丟一整份CSV，然後問「ETH會不會漲」可靠得多。
AI 適合處理的工作
Blockworks Data API與AI結合後，適合自動化：
- 每日鏈上數據摘要
- 多條公鏈營運比較
- 協議收入異常偵測
- ETF與鏈上資金流交叉分析
- 企業加密資產儲備監控
- 研究報告初稿
- 指標背離提醒
- DAO治理與基本面資料彙整
AI 不應該直接負責的工作
AI不適合自行決定：
- 指標定義
- 財務比率公式
- 缺值填補方式
- 異常值是否刪除
- 不同公鏈是否能直接比較
- 真實交易下單
- 槓桿與部位大小
語言模型很擅長替數字組織故事。危險也正在這裡：只要給它兩條同時上升的曲線，它很容易替你補出一段聽起來合理的因果關係。
所以我會要求AI在每個結論旁附上：
- 使用的指標
- 觀察期間
- 起始值與結束值
- 變化幅度
- 資料來源
- 資料擷取時間
- 信心水準
- 可能的替代解釋
沒有這些資訊的「智能分析」，通常只是寫得比較流暢的市場評論。
一個實用的 AI 分析範例
假設系統發現Solana的DEX交易量大幅成長，可以先產生以下結構：
{
"project": "solana",
"observation_date": "2026-08-20",
"signals": {
"dex_volume_7d_change": 42.3,
"active_addresses_7d_change": 8.1,
"stablecoin_supply_7d_change": 1.7,
"revenue_7d_change": 13.4
}
}接著再讓AI分析。
比較好的輸出應該是：
「Solana DEX交易量七日增加42.3%，但穩定幣供應只增加1.7%，代表交易活動增幅明顯高於鏈上資金存量。這可能來自既有資金周轉加快、短期投機或機器人活動，尚不足以證明有大規模新資金進入。」
比較危險的輸出則是：
「Solana生態全面爆發，大量資金正在進場，SOL可能即將大漲。」
兩段話都能由同一組資料產生。差別不在AI是否聰明，而在工作流程有沒有要求它區分觀察、解釋與預測。
使用 Blockworks Data API 最常見的五個錯誤
錯誤一：直接比較不同鏈的活躍地址
Ethereum、Bitcoin、Solana與各種Layer 2的帳戶及交易模型不同。
一個地址可能代表一名使用者，也可能是機器人、交易路由器、交易所熱錢包或智能合約。Solana高頻交易產生的地址與交易數，不能直接拿來和Ethereum L1判斷誰的「真實用戶」比較多。
錯誤二：把美元收入成長當成使用量成長
如果原生代幣價格上漲，即使使用者支付的代幣數量不變，美元計價收入也會增加。
研究收入時，最好同時觀察原生代幣與美元計價版本，避免把價格效果誤認成業務成長。
錯誤三：忽略 SUM 與 LAST
交易量通常適合使用SUM，TVL、供應量與持倉則通常使用期間最後一個數值。
如果把每日TVL加總成月度TVL，最後會得到一個很大的數字，但那個數字沒有實際經濟意義。
Blockworks API的aggregation欄位會標示指標聚合方式，建立資料管道時應保留下來。
錯誤四：沒有處理歷史修訂
鏈上資料可能因區塊重組、標籤更新、延遲資料或方法調整而被修正。
不要假設昨天存下來的歷史值永遠不會改。可以定期重新抓取短期窗口，並針對大幅修訂發出資料品質警報。
錯誤五：讓每個使用者直接呼叫 API
這不只會快速消耗額度，也可能讓API Key暴露在瀏覽器或手機App中。
正確方式是由後端統一呼叫Blockworks API，再把必要結果提供給前端。官方也明確建議不要把Key嵌入客戶端應用程式。
Blockworks Data API、Dune與DefiLlama怎麼選？
這三種工具的定位並不完全相同。
Blockworks Data API 適合需要標準化指標、研究圖表、ETF、協議收入與企業儲備資料的團隊。優點是資料已經整理好，接入速度快；限制則是只能使用平台提供的指標與項目。
Dune 適合需要自訂SQL、深入分析合約事件與建立特殊鏈上指標的研究者。自由度比較高，但也需要自行負責查詢邏輯、資料建模與驗證。Blockworks 本身也公開表示，其部分內部資料管道會使用Dune的索引與分析基礎設施。Dune Blockworks 案例
DefiLlama 適合快速取得TVL、穩定幣、收益、DEX交易量與協議費用等廣泛DeFi資料，而且提供免費API與付費Pro API。DefiLlama API官方文件
如果需要單筆交易、地址或即時合約狀態，則應直接使用RPC、區塊瀏覽器或鏈上索引服務。
我不會把它們看成四選一。比較成熟的資料管道通常會使用Blockworks取得標準化研究指標、Dune處理自訂鏈上查詢，再用RPC或其他來源做關鍵數字驗證。
Blockworks Data API 常見問題
以下問題是以「Blockworks API怎麼用」、「Blockworks Data API Python」、「Blockworks API rate limit」及「onchain data API for AI analysis」等中英文自然問句測試搜尋與AI答案頁後，反覆出現的實際需求。
Blockworks Data API 是免費的嗎？
目前官方文件顯示，Standard Blockworks Research方案每月包含2,500次API請求。這不是完全公開、無須登入的免費API，使用者需要Blockworks Research帳戶及具備相應權限的API Key。
Blockworks Data API 如何驗證身分？
所有請求都要在HTTP Header中加入x-api-key。金鑰可從Blockworks Research的Account Management頁面建立，並且與帳戶的團隊及方案綁定。
Blockworks API 可以取得即時價格嗎？
Assets端點可以取得資產價格及市場資訊，但大部分鏈上Metrics採用日頻資料。若需要秒級成交、訂單簿或即時資金費率，應使用交易所行情API。
Blockworks API 可以用Python串接嗎？
可以。使用requests送出GET請求，再將JSON轉換成Pandas DataFrame即可。官方文件也提供Python、cURL與TypeScript範例。
Blockworks Data API 可以直接接入 ChatGPT 或其他 AI 嗎？
可以透過自己的後端、函式工具或AI Agent呼叫API，但不建議讓語言模型直接處理未驗證的原始回應。較穩定的方式是先完成資料清理、統計計算與異常檢查，再把結構化摘要交給AI解讀。
Blockworks API 適合量化交易嗎？
適合研究日頻基本面因子、回測及市場狀態分類，但不適合作為高頻交易的唯一資料源。正式回測還必須處理資料發布時間、歷史修訂與前視偏誤。
每月2,500次請求夠用嗎？
對每日更新的個人研究或小型儀表板通常足夠，但前提是使用快取、批次查詢與增量更新。如果每次開啟頁面都重新呼叫API，額度很快就會耗盡。
結語：API 讓資料流動，判斷仍然需要人
Blockworks Data API最實際的價值，不是讓我們取得更多數字，而是讓同一套數字可以穩定、重複地進入分析流程。
當資料管道建立完成，研究人員不必每天下載CSV，可以把時間用在更重要的問題上：協議收入為什麼增加、穩定幣是否真的流入、ETF買盤能否持續，以及鏈上活動背後究竟是使用者還是機器人。
AI則可以協助整理異常、生成摘要與提出驗證方向，但它不應該代替指標定義、資料品質檢查與風險管理。
對我來說，一套真正有用的智能分析系統，不是每天告訴我哪個幣會漲，而是在市場出現一張漂亮圖表時，先提醒我確認樣本、時間尺度、資料來源，以及還有哪些合理解釋。
資料越容易取得，懷疑反而越不能省略。
立即體驗安全可靠的交易平台，點擊加入： https://www.okx.com/join?channelId=42974376
