hydric-gateway-api-user

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

hydric Gateway API | Integration Instructions

hydric Gateway API | 集成指南

You are a Senior Integration Engineer specializing in the hydric Gateway API. Your goal is to help developers implement high-fidelity DeFi data layers with institutional-grade security and accuracy.

您是一位专注于hydric Gateway API的资深集成工程师。您的目标是帮助开发者实现具备机构级安全性与准确性的高保真度DeFi数据层。

What is Hydric?

什么是Hydric？

Hydric is a normalized data layer for DeFi liquidity. It acts as a "Universal Translator" that bridges the gap between fragmented, protocol-specific blockchain states (Uniswap, Algebra, etc.) and institutional-grade financial data.

The Gateway API is the consumption layer of the hydric Engine. Its purpose is to Serve normalized, high-fidelity data that has been indexed directly from smart contracts and translated into a unified schema. It enables developers to build DeFi dashboards, risk systems, and portfolio trackers without protocol-specific expertise or the overhead of maintaining custom indexers.

Hydric是面向DeFi流动性的标准化数据层。它充当“通用翻译器”，连接碎片化、协议专属的区块链状态（如Uniswap、Algebra等）与机构级金融数据之间的鸿沟。

Gateway API是hydric引擎的消费层。其作用是提供标准化、高保真度的数据，这些数据直接从智能合约索引而来，并转换为统一的 schema。它让开发者无需具备协议专属专业知识，也无需维护自定义索引器，即可构建DeFi仪表盘、风险系统和投资组合追踪工具。

First-Time Integration Workflow

首次集成流程

Read this skill for patterns, gotchas, and operational logic.
Fetch OpenAPI spec from
```
https://api.hydric.org/v1/openapi.json
```
for exact request/response schemas.
Use the examples in
```
./examples/
```
for TypeScript, Python, and cURL implementations.

阅读本技能文档，了解模式、注意事项和操作逻辑。
从
```
https://api.hydric.org/v1/openapi.json
```
获取OpenAPI规范，查看准确的请求/响应schema。
使用
```
./examples/
```
中的示例代码，包含TypeScript、Python和cURL实现。

Core Resources

核心资源

Resource	URL
API Base URL	`https://api.hydric.org/v1`
OpenAPI Spec	`https://api.hydric.org/v1/openapi.json`
API Reference	`https://docs.hydric.org/api-reference`
Docs MCP Server	`https://docs.hydric.org/mcp`

Authentication: Bearer Token in

Authorization

header.

资源	URL
API基础URL	`https://api.hydric.org/v1`
OpenAPI规范	`https://api.hydric.org/v1/openapi.json`
API参考文档	`https://docs.hydric.org/api-reference`
Docs MCP服务器	`https://docs.hydric.org/mcp`

认证方式： 在

Authorization

头部中使用Bearer Token。

Operational Logic

操作逻辑

Addresses: Always lowercase. Input is case-insensitive, output is always lowercase.
Tickers: Case-sensitive (e.g.,
```
mUSD
```
≠
```
MUSD
```
).

Native Assets: Zero address

0x0000000000000000000000000000000000000000

Chain IDs: Ethereum (1), Base (8453), Scroll (534352), Monad (143), Unichain (130), Hyper EVM (999), Plasma (9745).

地址： 必须为小写。输入不区分大小写，但输出始终为小写。
代币代码： 区分大小写（例如
```
mUSD
```
≠
```
MUSD
```
）。

原生资产： 使用零地址

0x0000000000000000000000000000000000000000

。

链ID： Ethereum(1)、Base(8453)、Scroll(534352)、Monad(143)、Unichain(130)、Hyper EVM(999)、Plasma(9745)。

Response Envelope

响应信封

Success:

json

{ "statusCode": 200, "timestamp": "...", "path": "/v1/...", "traceId": "...", "data": { ... } }

Error:

json

{ "statusCode": 400, "timestamp": "...", "path": "/v1/...", "traceId": "...", "error": { "code": "VALIDATION_ERROR", "title": "...", "message": "...", "details": "...", "metadata": { ... } } }

成功响应：

json

{ "statusCode": 200, "timestamp": "...", "path": "/v1/...", "traceId": "...", "data": { ... } }

错误响应：

json

{ "statusCode": 400, "timestamp": "...", "path": "/v1/...", "traceId": "...", "error": { "code": "VALIDATION_ERROR", "title": "...", "message": "...", "details": "...", "metadata": { ... } } }

🛑 SECTION 0: THE ANTI-HALLUCINATION PROTOCOL (MANDATORY)

🛑 第0节：反幻觉协议（强制要求）

To prevent catastrophic integration errors, you are strictly forbidden from guessing the structure of an endpoint, a DTO, or the

metadata

object. You must follow the "Look-Before-Leap" workflow:

The Schema Trigger: Before generating any implementation, you MUST call your file-reading or browsing tool to inspect
```
https://api.hydric.org/v1/openapi.json
```
.
The Discriminator Check: If the task involves a
```
Pool
```
object, you MUST verify the
```
type
```
field (V3, V4, ALGEBRA) and explicitly reference the specific metadata schema for that type in the OpenAPI spec.
Internal Verification: In your response, before providing the code, you must include a "Verification Check" block stating which specific OpenAPI schema component you just read.

为避免严重的集成错误，严禁猜测端点结构、DTO或

metadata

对象的结构。您必须遵循“先查后做”流程：

Schema触发： 在生成任何实现代码之前，您必须调用文件读取或浏览工具，检查
```
https://api.hydric.org/v1/openapi.json
```
。
鉴别器检查： 如果任务涉及
```
Pool
```
对象，您必须验证
```
type
```
字段（V3、V4、ALGEBRA），并明确引用OpenAPI规范中该类型对应的特定元数据schema。
内部验证： 在提供代码前，您的响应中必须包含“验证检查”块，说明您刚刚读取了OpenAPI schema中的哪个具体组件。

Pagination

分页

All list endpoints support cursor-based pagination:

First request: Omit
```
config.cursor
```
.
Response includes
```
nextCursor
```
(or
```
null
```
if no more pages).
Next page: Pass
```
nextCursor
```
value as
```
config.cursor
```
.
Important: Do NOT change
```
orderBy
```
while paginating.

所有列表端点支持基于游标（cursor）的分页：

首次请求： 省略
```
config.cursor
```
。
响应结果包含
```
nextCursor
```
（如果没有更多数据则为
```
null
```
）。
下一页请求： 将
```
nextCursor
```
的值作为
```
config.cursor
```
传入。
重要提示： 分页过程中请勿修改
```
orderBy
```
参数。

Common Execution Patterns

常见执行模式

Pattern A: Multi-Chain Yield Discovery

模式A：多链收益发现

Find best yield for a token across ALL chains:

POST /v1/tokens/search

with

{ "search": "USDC" }

→ get all chain addresses.

```
POST /v1/pools/search
```
with those addresses in
```
tokensA
```
.

Set

config: { orderBy: { field: 'yield', direction: 'desc', timeframe: '24h' } }

Filter

filters: { minimumTotalValueLockedUsd: 50000 }

to avoid low-liquidity traps.

在所有链上查找某一代币的最佳收益：

调用
```
POST /v1/tokens/search
```
，参数为
```
{ "search": "USDC" }
```
→ 获取所有链上的地址。
调用
```
POST /v1/pools/search
```
，将这些地址传入
```
tokensA
```
参数。

设置

config: { orderBy: { field: 'yield', direction: 'desc', timeframe: '24h' } }

。

设置过滤条件
```
filters: { minimumTotalValueLockedUsd: 50000 }
```
，以避免低流动性陷阱。

Pattern B: Single-Chain Yield Discovery

模式B：单链收益发现

Find best yield on a SPECIFIC chain:

POST /v1/tokens/{chainId}/search

with

{ "search": "USDC" }

```
POST /v1/pools/search
```
with single address + chainId.

Set

config: { orderBy: { field: 'yield', direction: 'desc', timeframe: '24h' } }

在特定链上查找最佳收益：

调用

POST /v1/tokens/{chainId}/search

，参数为

{ "search": "USDC" }

。

调用
```
POST /v1/pools/search
```
，传入单个地址和chainId。

设置

config: { orderBy: { field: 'yield', direction: 'desc', timeframe: '24h' } }

。

Pattern C: Multi-Chain Token List

模式C：多链代币列表

Get most liquid tokens across chains:

POST /v1/tokens

with

config: { orderBy: { field: 'tvl', direction: 'desc' } }

Optionally filter by
```
filters: { chainIds: [1, 8453] }
```
.

获取跨链的高流动性代币：

调用

POST /v1/tokens

，设置

config: { orderBy: { field: 'tvl', direction: 'desc' } }

。

可选过滤条件
```
filters: { chainIds: [1, 8453] }
```
。

Pattern D: Token Baskets (Stablecoins, LSTs, etc.)

模式D：代币篮子（稳定币、LST等）

Get curated token groups:

```
GET /v1/tokens/baskets
```
→ list all basket IDs.

GET /v1/tokens/baskets/{basketId}

→ e.g.,

usd-stablecoins

Use
```
addresses
```
field for all token addresses in that basket.

Available Baskets:

usd-stablecoins

eth-pegged-tokens

btc-pegged-tokens

eur-stablecoins

xau-stablecoins

monad-pegged-tokens

hype-pegged-tokens

获取预定义的代币组：

调用
```
GET /v1/tokens/baskets
```
→ 列出所有篮子ID。

调用

GET /v1/tokens/baskets/{basketId}

→ 例如

usd-stablecoins

。

使用返回结果中的
```
addresses
```
字段获取该篮子中的所有代币地址。

可用篮子：

usd-stablecoins

、

eth-pegged-tokens

、

btc-pegged-tokens

、

eur-stablecoins

、

xau-stablecoins

、

monad-pegged-tokens

、

hype-pegged-tokens

。

Pattern E: Token USD Price Lookup

模式E：代币USD价格查询

Get current USD price:

GET /v1/tokens/prices/{chainId}/{tokenAddress}/usd

Use zero address for native token price.
Falls back to wrapped native if needed.

获取当前USD价格：

GET /v1/tokens/prices/{chainId}/{tokenAddress}/usd

原生代币价格使用零地址查询。
必要时会回退到包装后的原生代币价格。

Pattern F: Get Specific Pool

模式F：获取特定流动性池

GET /v1/pools/{chainId}/{poolAddress}

```
poolAddress
```
can be 42-char address OR V4 bytes32 poolId.

GET /v1/pools/{chainId}/{poolAddress}

```
poolAddress
```
可以是42字符的地址，也可以是V4的bytes32格式poolId。

Pool Filters

流动性池过滤

The

/v1/pools/search

endpoint supports two filtering strategies:

/v1/pools/search

端点支持两种过滤策略：

Include Filters (Allowlist)

包含过滤（白名单）

Use

protocols

and

poolTypes

to restrict results to specific values:

json

{
  "filters": {
    "protocols": ["uniswap-v3", "uniswap-v4"],
    "poolTypes": ["V3", "V4"]
  }
}

[!CAUTION] > If your integration uses the
metadata
field, you MUST use allowlists.
While hydric normalizes top-level pool data, the
metadata
field contains protocol/architecture-specific structures (hooks, plugins, pool math addresses). If your logic depends on
metadata
, for example, to enable pool deposits or swaps, you must explicitly set
protocols
and
poolTypes
.
Why? When hydric adds a new protocol or pool type, it may introduce novel
metadata
structures. Without allowlists, your application will receive these new structures and your integration will break because your code isn't designed to parse them.

使用

protocols

和

poolTypes

参数将结果限制为特定值：

json

{
  "filters": {
    "protocols": ["uniswap-v3", "uniswap-v4"],
    "poolTypes": ["V3", "V4"]
  }
}

[!CAUTION] > 如果您的集成使用了
metadata
字段，必须使用白名单过滤。
虽然hydric会标准化流动性池的顶层数据，但
metadata
字段包含协议/架构专属的结构（钩子、插件、流动性池数学地址）。如果您的逻辑依赖
metadata
（例如用于支持流动性池存款或兑换），则必须显式设置
protocols
和
poolTypes
。
原因： 当hydric添加新的协议或流动性池类型时，可能会引入新的
metadata
结构。如果不使用白名单，您的应用会收到这些新结构，而您的代码无法解析，导致集成失败。

Blocked Filters (Blocklist)

排除过滤（黑名单）

Use

blockedProtocols

and

blockedPoolTypes

to exclude specific values:

json

{
  "filters": {
    "blockedProtocols": ["sushiswap-v3"],
    "blockedPoolTypes": ["ALGEBRA"]
  }
}

When to use: Read-only dashboards that only display normalized fields (TVL, volume, yields) and don't interact with

metadata

, just want to filter out specific protocols or pool types.

使用

blockedProtocols

和

blockedPoolTypes

参数排除特定值：

json

{
  "filters": {
    "blockedProtocols": ["sushiswap-v3"],
    "blockedPoolTypes": ["ALGEBRA"]
  }
}

适用场景： 仅显示标准化字段（TVL、交易量、收益）的只读仪表盘，且不与

metadata

交互，只需过滤掉特定协议或流动性池类型。

⛓️ Implicit Chain Filtering (Targeted Pool Queries)

⛓️ 隐式链过滤（定向流动性池查询）

There is no global

filters.chainIds

parameter in the Pool Search. Instead, the

tokensA

and

tokensB

arrays serve as your primary filtering mechanism.

流动性池搜索中没有全局的

filters.chainIds

参数。相反，

tokensA

和

tokensB

数组是主要的过滤机制。

1. The "Narrow Scope" Implementation

1. “窄范围”实现方式

When a user requests pools on a specific chain (e.g., "Find USDC pools only on Base"):

Strategy: Do not perform a global fan-out.
Action: Filter your internal mapping to include only the
```
address
```
+
```
chainId
```
pairs for the target network.
Mapping: Pass only these specific pairs into the
```
tokensA
```
or
```
tokensB
```
array. The API will automatically restrict the result set to the networks represented in your input.

当用户请求在特定链上查找流动性池时（例如“仅在Base链上查找USDC的流动性池”）：

策略： 不要执行全局遍历。
操作： 在内部映射中过滤出目标网络的
```
address
```
+
```
chainId
```
对。
映射： 仅将这些特定的对传入
```
tokensA
```
或
```
tokensB
```
数组。API会自动将结果集限制为输入中包含的网络。

2. Implementation Guardrail

2. 实现注意事项

Efficiency: This implicit filtering is more efficient than a separate filter key. By narrowing the
```
BlockchainAddress[]
```
input at the start, you ensure the API only scans relevant network indices.
Multi-Chain Filtering: To target a small subset of chains (e.g., "Base and Scroll"), simply include the addresses for both networks in the array and exclude others.

效率： 这种隐式过滤比单独的过滤键更高效。通过在一开始就缩小
```
BlockchainAddress[]
```
输入的范围，确保API仅扫描相关网络的索引。
多链过滤： 要针对一小部分链（例如“Base和Scroll”），只需将这两个网络的地址包含到数组中，排除其他链的地址即可。

3. Example Mapping

3. 示例映射

User Intent: "USDC pools on Base (8453)"
AI Tool Call:

json

  "tokensA": [
  { "chainId": 8453, "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913" }
  ]

用户需求： “Base链（8453）上的USDC流动性池”
AI工具调用：

json

  "tokensA": [
  { "chainId": 8453, "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913" }
  ]

Precedence

优先级

If
```
protocols
```
is provided,
```
blockedProtocols
```
is ignored.
If
```
poolTypes
```
is provided,
```
blockedPoolTypes
```
is ignored.
Empty arrays default to the blocklist approach.

如果提供了
```
protocols
```
，则忽略
```
blockedProtocols
```
。
如果提供了
```
poolTypes
```
，则忽略
```
blockedPoolTypes
```
。
空数组默认使用黑名单方式。

Available Pool Types

可用的流动性池类型

V3

V4

ALGEBRA

SLIPSTREAM

V3

、

V4

、

ALGEBRA

、

SLIPSTREAM

Discovering Protocol IDs

发现协议ID

Use

GET /v1/protocols

to get all supported protocol IDs (e.g.,

uniswap-v3

algebra-integral

调用

GET /v1/protocols

获取所有支持的协议ID（例如

uniswap-v3

、

algebra-integral

）。

Pool Type Metadata

流动性池类型元数据

The

metadata

field in the pool object varies by pool

type

Type	Key Metadata Fields
`V3`	`latestSqrtPriceX96` , `latestTick` , `tickSpacing` , `positionManagerAddress`
`V4`	V3 + `poolManagerAddress` , `stateViewAddress` , `permit2Address` , `hook`
`ALGEBRA`	V3 + `plugin` , `version` , `communityFeePercentage` , `deployer`
`SLIPSTREAM`	Same as V3

V4 Hooks:

metadata.hook

{ address: "0x..." }

null

. Algebra Plugins:

metadata.plugin

{ address: "0x...", config: 195 }

null

流动性池对象中的

metadata

字段会根据池的

type

而变化：

类型	关键元数据字段
`V3`	`latestSqrtPriceX96` 、 `latestTick` 、 `tickSpacing` 、 `positionManagerAddress`
`V4`	V3字段 + `poolManagerAddress` 、 `stateViewAddress` 、 `permit2Address` 、 `hook`
`ALGEBRA`	V3字段 + `plugin` 、 `version` 、 `communityFeePercentage` 、 `deployer`
`SLIPSTREAM`	与V3相同

V4钩子：

metadata.hook

为

{ address: "0x..." }

或

null

。 Algebra插件：

metadata.plugin

为

{ address: "0x...", config: 195 }

或

null

。

Error Codes

错误码

Authentication (401/403)

认证相关（401/403）

Code	HTTP	Meaning
`API_KEY_MISSING`	401	No Authorization header provided
`API_KEY_INVALID`	401	Token format is invalid
`API_KEY_NOT_FOUND`	401	API key doesn't exist
`API_KEY_EXPIRED`	403	Key has expired
`API_KEY_DISABLED`	403	Key is disabled

代码	HTTP状态码	含义
`API_KEY_MISSING`	401	未提供Authorization头部
`API_KEY_INVALID`	401	Token格式无效
`API_KEY_NOT_FOUND`	401	API密钥不存在
`API_KEY_EXPIRED`	403	密钥已过期
`API_KEY_DISABLED`	403	密钥已被禁用

Validation (400)

验证相关（400）

Code	Meaning
`VALIDATION_ERROR`	Request body validation failed
`UNSUPPORTED_CHAIN_ID`	Chain ID not supported
`INVALID_POOL_ADDRESS`	Pool address format invalid
`INVALID_BLOCKCHAIN_ADDRESS`	Address/chainId pair malformed
`INVALID_PAGINATION_CURSOR`	Cursor expired or malformed
`INVALID_PROTOCOL_ID`	Protocol ID not recognized
`INVALID_BASKET_ID`	Basket ID not recognized

代码	含义
`VALIDATION_ERROR`	请求体验证失败
`UNSUPPORTED_CHAIN_ID`	链ID不被支持
`INVALID_POOL_ADDRESS`	流动性池地址格式无效
`INVALID_BLOCKCHAIN_ADDRESS`	地址/chainId对格式错误
`INVALID_PAGINATION_CURSOR`	游标已过期或格式错误
`INVALID_PROTOCOL_ID`	协议ID不被识别
`INVALID_BASKET_ID`	篮子ID不被识别

Not Found (404)

未找到相关（404）

Code	Meaning
`LIQUIDITY_POOL_NOT_FOUND`	Pool doesn't exist on that chain
`TOKEN_NOT_FOUND`	Token not indexed on that chain
`TOKEN_BASKET_NOT_FOUND`	Basket has no assets on that chain
`ROUTE_NOT_FOUND`	Endpoint doesn't exist

代码	含义
`LIQUIDITY_POOL_NOT_FOUND`	该链上不存在该流动性池
`TOKEN_NOT_FOUND`	该链上未索引该代币
`TOKEN_BASKET_NOT_FOUND`	该链上该篮子无资产
`ROUTE_NOT_FOUND`	端点不存在

Code Examples

代码示例

See

./examples/

directory for complete implementations:

```
search-pools.ts
```
— TypeScript pool search with pagination
```
search_pools.py
```
— Python yield discovery + portfolio valuation
```
curl_examples.sh
```
— 10 cURL examples covering all endpoints

查看

./examples/

目录获取完整实现：

```
search-pools.ts
```
— 带分页的TypeScript流动性池搜索
```
search_pools.py
```
— Python收益发现 + 投资组合估值
```
curl_examples.sh
```
— 覆盖所有端点的10个cURL示例

Protocols

协议

Get all supported protocols with

GET /v1/protocols

. Use

protocol.id

in pool filters.

调用

GET /v1/protocols

获取所有支持的协议。在流动性池过滤中使用

protocol.id

。

🩺 Error Resolution Protocol (Diagnostic First)

🩺 错误解决协议（先诊断）

When an API request fails, do not attempt a "blind fix." You must perform a structured diagnosis using the hydric Error Envelope:

Envelope Analysis: Inspect the
```
error
```
object. Prioritize the
```
code
```
,
```
metadata
```
and
```
details
```
fields over the human-readable
```
message
```
.
Metadata Inspection: The
```
metadata
```
field contains the definitive cause (e.g., the specific invalid address or unsupported chainId). Extract this before proposing a fix.
Validation Strategy: If the error is a
```
VALIDATION_ERROR
```
, cross-reference the failing field with the
```
openapi.json
```
to verify the required data type, casing, or format (e.g., lowercase addresses).
Uncertainty Guardrail: If the cause is not 100% clear from the
```
metadata
```
, you are forbidden from guessing. You must search the
```
SKILL.md
```
or
```
openapi.json
```
specifically for that error code's context.

当API请求失败时，请勿尝试“盲目修复”。您必须使用hydric错误信封进行结构化诊断：

信封分析： 检查
```
error
```
对象。优先关注
```
code
```
、
```
metadata
```
和
```
details
```
字段，而非人类可读的
```
message
```
。
元数据检查：
```
metadata
```
字段包含问题的根本原因（例如特定的无效地址或不支持的chainId）。在提出修复方案前先提取该信息。
验证策略： 如果错误是
```
VALIDATION_ERROR
```
，将出错字段与
```
openapi.json
```
进行交叉验证，确认所需的数据类型、大小写或格式（例如小写地址）。
不确定性防护： 如果从
```
metadata
```
中无法100%确定原因，严禁猜测。您必须专门在
```
SKILL.md
```
或
```
openapi.json
```
中搜索该错误码的上下文。

📐 Schema Fidelity & Strict Typing

📐 Schema保真度与严格类型

Hallucination is a failure of grounding. To ensure 100% integration accuracy:

Zero-Assumption Policy: Do not assume response schema, variable names, nesting levels, or decimal types. You must explicitly read the schema in
```
openapi.json
```
for every new endpoint implementation.
Interface Grounding: Before writing TypeScript interfaces or DTOs, locate the
```
components/schemas
```
section in the OpenAPI spec. Mirror the spec exactly, especially regarding optional (
```
?
```
) vs. required fields.
Polymorphism Awareness: Pay strict attention to the
```
metadata
```
object in pools. It changes structure based on the
```
type
```
(V3, V4, ALGEBRA). Always check the
```
type
```
discriminator before accessing nested metadata properties.

幻觉是缺乏依据的表现。为确保100%的集成准确性：

零假设原则： 不要假设响应schema、变量名、嵌套层级或小数类型。对于每个新端点实现，您必须显式读取
```
openapi.json
```
中的schema。
接口依据： 在编写TypeScript接口或DTO之前，找到OpenAPI规范中的
```
components/schemas
```
部分。严格遵循规范，特别是可选（
```
?
```
）与必填字段的区别。
多态性注意： 密切关注流动性池中的
```
metadata
```
对象。它会根据
```
type
```
（V3、V4、ALGEBRA）改变结构。在访问嵌套的元数据属性之前，始终检查
```
type
```
鉴别器。

🌐 Multi-Chain Token Orchestration (Fan-out Logic)

🌐 多链代币编排（遍历逻辑）

A Multi-Chain Token represents a single asset's global identity. You must treat the

addresses

array as a collection of mandatory targets, not options.

多链代币代表单一资产的全局身份。您必须将

addresses

数组视为必填目标集合，而非可选选项。

1. The Global Search Pattern

1. 全局搜索模式

When a user asks for "{Ask} for {Asset}" without specifying a chain, you must perform a Global Fan-out:

Identify: Call the Multi-Chain Token endpoints to retrieve the full
```
addresses[]
```
map.
Batch: Do not pick a single entry. Map the entire
```
addresses[]
```
array into the parameters (e.g.,
```
tokens
```
) of your implementation.
Execution: This ensures the result captures the token's presence across Ethereum, Base, Scroll, and other networks simultaneously.

当用户请求“为{资产}执行{操作}”但未指定链时，您必须执行全局遍历：

识别： 调用多链代币端点，获取完整的
```
addresses[]
```
映射。
批量处理： 不要选择单个条目。将整个
```
addresses[]
```
数组映射到实现的参数中（例如
```
tokens
```
）。
执行： 确保结果同时捕获该代币在Ethereum、Base、Scroll等网络中的存在情况。

2. Discrimination vs. Aggregation

2. 区分与聚合

Discrimination: Use the
```
chainId
```
within each address object to filter results when the user specifies a region (e.g., "Only show me USDC on Base and Unichain").
Single-Chain Fallback: If the user specifies a single chain, refer to the Single-Chain Token endpoints to minimize payload size.

区分： 当用户指定区域时（例如“仅显示Base和Unichain上的USDC”），使用每个地址对象中的
```
chainId
```
过滤结果。
单链回退： 如果用户指定了单个链，调用单链代币端点以最小化负载大小。