跳轉到主要內容

​
概述

每條 GraphQL 查詢會根據所查 Cube、請求行數與聚合複雜度消耗 Credit Units (CU)。Credits 與 REST API 使用同一套計費計劃 — 你的 API Key 在兩者間通用。
GraphQL API 與 REST Data API 共用同一 API Key 與計費計劃。GraphQL 查詢消耗的 Credits 計入整體用量。

​
Credit 計算公式

Credits 按 Cube 分別計算，公式如下： 
Credits = BaseCost × LimitFactor × AggregationFactor × MetricFactor
FactorCalculationDescription
BaseCost各 Cube 基礎價（見下表）隨 Cube 複雜度變化的固定成本
LimitFactorceil(limit / 100)，最小為 1隨請求行數縮放
AggregationFactor1.0（無）、1.5（GROUP BY）、2.0（HAVING）使用聚合或 HAVING 過濾時更高
MetricFactor1.0 + (metric_count × 0.2)每增加一個 metric（如 count、sum）都會提高
在預設 limit（25 行）且無聚合的簡單查詢中，通常只支付基礎成本。提高行數或增加聚合類 metric 時，Credits 會上升。

​
計算示例

BaseCost = 50, LimitFactor = ceil(10/100) = 1
AggregationFactor = 1.0, MetricFactor = 1.0
Credits = 50 × 1 × 1.0 × 1.0 = 50 CU

BaseCost = 50, LimitFactor = ceil(500/100) = 5
AggregationFactor = 1.0, MetricFactor = 1.0
Credits = 50 × 5 × 1.0 × 1.0 = 250 CU

BaseCost = 50, LimitFactor = ceil(500/100) = 5
AggregationFactor = 1.5 (GROUP BY), MetricFactor = 1.0 + 2×0.2 = 1.4
Credits = 50 × 5 × 1.5 × 1.4 = 525 CU

​
各 Cube 基礎成本

CubeBase Cost (CU)說明
DEXTrades50維度最多、體量最大的表
DEXTradeByTokens50與 DEXTrades 同源資料
DEXPoolEvents30流動性事件
Pairs30OHLC K 線資料（Trading 組）
Tokens30代幣成交統計（Trading 組）
WalletTokenPnL25DWS 彙總
Transfers15
BalanceUpdates10
Events、Calls20EVM 專屬事件/呼叫追蹤
Instructions20Solana 專屬
PredictionTrades20預測市場資料
其餘所有 Cube20預設基礎成本
基礎成本反映查詢複雜度與各 Cube 底層資料規模。extensions.credits 中返回的實際 Cube 名稱由服務端決定 — 請以響應值為計費依據。

​
響應：extensions.credits

每條 GraphQL 響應都會在 extensions 中附帶 Credits 消耗詳情： 
{
  "data": {
    "DEXTrades": [ ... ]
  },
  "extensions": {
    "credits": {
      "total": 50,
      "cubes": [
        {
          "cube": "DEXTrades",
          "credits": 50,
          "row_count": 10
        }
      ]
    }
  }
}
FieldTypeDescription
totalInt整條查詢消耗的 Credits 合計
cubesArray按 Cube 拆分
cubes[].cubeStringCube 名稱
cubes[].creditsInt該 Cube 計費的 Credits
cubes[].row_countInt返回行數
在發生扣費（即 total > 0）時會出現 extensions.credits。即使返回 0 行，仍會收取基礎成本。

​
在 IDE 中檢視用量

GraphQL IDE 狀態列會在每次查詢後顯示 Credits 消耗：
  • CU 指示：顯示消耗的 CU 總數（例如 50 CU）
  • Latency：請求耗時（毫秒）
  • Response size：響應體大小

​
最佳化 Credits 使用的建議

少選欄位

只請求需要的維度欄位。欄位越少，處理的資料量通常越小。

合理 limit

在業務允許範圍內儘量壓低 limit.count。Credits 隨 ceil(limit / 100) 縮放。

優先預聚合 Cube

需要彙總資料時，優先使用 DWM/DWS Cube（如 Pairs、Tokens、TokenHolders），而不是在 DWD Cube（如 DEXTrades）上堆 metrics。

​
相關文件

計費與 Units 總覽

ChainStream 計費計劃、單位配額與支付方式概覽。

Metrics 與聚合

瞭解聚合 metrics 如何影響查詢 Credits。