stablelabs · probablyangg · Jul 24, 2026 · Jul 24, 2026 · Jul 24, 2026
diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md
@@ -48,9 +48,11 @@ Before returning any page, read it back and answer these four questions. Fix any
 | STABLE | Referring to the token (all caps) | Stable (when meaning the token), stable |
 | StableChain | Referring to the underlying settlement layer / protocol (capital S and C) | Stablechain, Stable chain, stablechain |
 | Stablechain | Only in the introductory definition ("Stable is the first Stablechain") | |
-| USDT | Referring to the asset | Tether (unless referring to the company) |
+| USDT | Referring to native USDT on a source chain, or to the broader asset where the distinction from USDT0 does not matter | Usdt, Tether (unless referring to the company) |
+| USDT0 | Referring to the omnichain asset, including Stable's native gas and settlement asset | Usdt0, USDT when referring specifically to the asset on Stable |
 
 - Use the product or protocol name exactly as branded (e.g., "LayerZero", "RedStone", "USDT0").
+- Never title-case an acronym or branded identifier. Write `USDT0`, `FAQ`, and `API`, not `Usdt0`, `Faq`, or `Api`.
 
 ### UI and keyboard actions
 
@@ -65,6 +67,11 @@ Before returning any page, read it back and answer these four questions. Fix any
 - Do not use title case (e.g., ~~"Gas Pricing And Fees"~~).
 - Vocs builds the right-side outline from your headings, so keep them short and scannable.
 
+### FAQ sections
+
+- In an FAQ section within a larger page, write each question as a `###` heading. This gives every question a visible hierarchy and a stable anchor.
+- On the dedicated `reference/faq.mdx` page, write each question as a bold paragraph ending in `?`. The structured-data parser uses that format to generate `FAQPage` question-and-answer entries.
+
 ## Frontmatter
 
 Every page must include these three fields, in this order:
@@ -120,6 +127,12 @@ Every page has exactly one home in the sidebar. Edit only the `/en` section of `
 
 When a concept is relevant to multiple sections (e.g., a Learn concept that readers also need mid-task in Build), keep it in its canonical section and surface it from the others through **content**, not navigation. Link to it from the relevant overview page inline. Concepts live in one place; task-oriented sections point at them.
 
+### Sidebar labels
+
+- Use sentence case for English sidebar labels.
+- Preserve the exact capitalization of acronyms, standards, and branded identifiers such as `USDT0`, `FAQ`, `API`, `JSON-RPC`, and `EIP-7702`.
+- Match the destination page's title unless the surrounding navigation provides context that allows a shorter label.
+
 ## Page structure
 
 Follow this general pattern:

diff --git a/docs/pages/cn/explanation/bank-module.mdx b/docs/pages/cn/explanation/bank-module.mdx
@@ -1,44 +1,44 @@
 ---
 source_path: explanation/bank-module.mdx
-source_sha: c19264aa3a4aa590a16f97192b30d5ffe1d88b08
+source_sha: d1e8701c692bce3df6e4d7c6e16cf350e18165ef
 title: "银行模块"
-description: "银行预编译合约暴露了与 ERC-20 兼容的代币转账以及由 SDK x/bank 模块支持的铸造、销毁和授权方法。"
+description: "银行预编译合约公开了与 ERC-20 兼容的代币转移以及由 SDK x/bank 模块支持的铸币、销毁和授权方法。"
 diataxis: "explanation"
 ---
 
 # 银行模块
 
-Stable SDK 中的 `x/bank` 模块处理代币余额、转账和供应。其 EVM 接口（**银行预编译合约**）封装了此模块，并添加了 ERC-20 语义以及一个用于特权铸币/销毁操作的授权层。需要在 Stable 上转移代币的合约可以直接调用预编译合约，而无需部署自己的代币实现。
+Stable 的 SDK 中的 `x/bank` 模块负责处理代币余额、转移和供应。其 EVM 接口（**银行预编译合约**）封装了该模块，并增加了 ERC-20 语义以及用于特权铸币/销毁操作的授权层。需要在 Stable 上转移代币的合约可以直接调用预编译合约，而无需部署自己的代币实现。
 
-## 它暴露了什么
+## 它公开了什么
 
 银行预编译合约提供了标准的 ERC-20 方法：
 
 - `transfer`、`balanceOf`、`totalSupply`
 - `approve`、`transferFrom`、`allowance`、`revoke`
 
-这些方法适用于任何调用者。无需注册。
+这些方法可以由任何调用者使用。无需注册。
 
 它还提供了特权方法：
 
 - `mint`: 铸造新代币并将其转移到账户。
 - `burn`: 销毁账户持有的代币。
-- `multiTransfer`: 通过单个调用将代币从一个发送方转移到多个接收方。
+- `multiTransfer`: 在单个调用中将代币从一个发送方转移到多个接收方。
 
-铸币和销毁要求调用合约通过治理提案在 `x/precompile` 允许列表中注册。治理代币的铸造被完全阻止。这使得供应通胀只受授权合约的限制。
+铸币和销毁需要通过治理提案将调用合约注册到 `x/precompile` 白名单中。治理代币的铸币被完全阻止。这使得供应膨胀仅限于授权合约。
 
-## 何时使用
+## 何时使用它
 
 - DeFi 合约需要代表用户转移 STABLE 或 USDT0：直接在预编译合约上调用 `transfer` 或 `transferFrom`。
 - 协议合约根据业务逻辑铸造或销毁代币：首先通过治理注册，然后调用 `mint` / `burn`。
-- 支付合约需要一对多支付：在单个交易中调用 `multiTransfer`，而不是循环转账。
+- 支付合约需要一对多支付：在单个事务中调用 `multiTransfer`，而不是循环转移。
 
-## 在哪里找到 ABI
+## 在哪里可以找到 ABI
 
-完整的方法签名、事件负载和授权流程在[银行预编译合约参考](/cn/reference/bank-module-api)中。
+完整的方法签名、事件负载和授权流程可在[银行预编译合约参考](/cn/reference/bank-module-api)中找到。
 
 ## 接下来推荐
 
-- [**银行预编译合约参考**](/cn/reference/bank-module-api)：调用 `transfer`、`approve`、`mint`、`burn` 并读取事件。
-- [**系统模块概览**](/cn/explanation/system-modules-overview)：返回预编译合约暴露的模块完整列表。
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解银行模块管理的双重资产模型。
+- [**银行预编译合约参考**](/cn/reference/bank-module-api)：调用 `transfer`、`approve`、`mint`、`burn`，并读取事件。
+- [**系统模块概述**](/cn/explanation/system-modules-overview)：返回预编译合约公开的模块完整列表。
+- [**USDT0 作为 gas**](/cn/explanation/usdt-as-gas-token)：了解银行模块管理的双重角色资产模型。
diff --git a/docs/pages/cn/explanation/confidential-transfer.mdx b/docs/pages/cn/explanation/confidential-transfer.mdx
@@ -1,60 +1,60 @@
 ---
 source_path: explanation/confidential-transfer.mdx
-source_sha: 44b9b0047f5252a2aa10b8e93a64f42854c9182d
-title: "保密转账"
-description: "Stable 网络上，符合监管要求的、隐私保护型 USDT 交易的保密转账机制。"
+source_sha: d4f49b5013bdf924bef68a0c154c4d23e524fa3d
+title: "机密传输"
+description: "Stable区块链上用于隐私保护的USDT交易，并符合监管要求的机密传输机制。"
 diataxis: "explanation"
 ---
 
-# 保密转账
+# 机密传输
 
-**保密转账**是 Stable 上的一个隐私层，可以在屏蔽 USDT0 转账**金额**的同时，保持发件人和收件人地址公开可见。屏蔽的金额只有交易双方和授权的监管审计人员才能读取。该机制使用零知识 (ZK) 加密来证明有效性，而无需透露具体金额。此功能正在开发中；本页面描述了目标模型。
+**机密传输**是Stable上的一个隐私层，它能在保持发送方和接收方地址公开可见的同时，**屏蔽**USDT0传输的**金额**。被屏蔽的金额只能由交易双方和授权的监管审计员读取，它使用零知识（ZK）密码学来证明有效性，而无需透露具体数值。此功能正在开发中；本页面描述了目标模型。
 
-## 它解决的问题
+## 它解决了什么问题
 
-标准链上转账是完全透明的；任何人都可以读取发件人、收件人和金额。对于商业支付，这种透明度是数据泄露问题：
+链上标准传输是完全透明的；任何人都可以读取发送方、接收方和金额。对商业支付而言，这种透明性带来了数据泄露问题：
 
-- 零售商在链上支付供应商的款项，会将订单量和批发价格暴露给任何观察者。
-- 财务部门在账户之间转移资金，会公开其仓位规模。
+- 零售商在链上向供应商付款，会向任何观察者暴露订单量和批发价格。
+- 财务部在账户之间转移资金，会公开其头寸规模。
 - 工资发放会将薪资数据发布到整个网络。
 
-完全不透明（Monero 风格）可以解决这个问题，但会破坏合规性：监管机构和审计人员无法验证交易。选择性保密（金额隐藏，各方可审计）是 Stable 的目标模式。
+完全不透明（Monero风格）可以解决这个问题，但会破坏合规性：监管机构和审计员无法核实交易。选择性保密（金额隐藏，各方可审计）是Stable的目标模型。
 
-## 什么可见，什么不可见
+## 什么可看，什么不可看
 
-| 字段 | 在链上可见 | 已屏蔽 |
+| 字段 | 链上可见 | 被屏蔽 |
 | :--- | :--- | :--- |
-| 发件人地址 | ✓ | |
-| 收件人地址 | ✓ | |
-| 转账金额 | | ✓ |
+| 发送方地址 | ✓ | |
+| 接收方地址 | ✓ | |
+| 传输金额 | | ✓ |
 | 辅助元数据 | | ✓ |
 
-屏蔽的金额经过加密。有效的证明可以证明转账是余额一致的（没有通货膨胀，没有负数），而不会透露金额本身。只有发件人、收件人和授权的监管审计人员才能解密屏蔽值。
+被屏蔽的金额是加密的。有效的证明可以表明传输是余额一致的（没有通货膨胀，没有负数金额），而无需透露数值本身。只有发送方、接收方和授权的监管审计员才能解密被屏蔽的数值。
 
 ## 它如何适应合规模型
 
-两个特性使设计可审计：
+两个属性使该设计可审计：
 
-- **确定性审计员访问。** 监管审计员持有密钥，可以解密其管辖范围内交易的屏蔽金额。商业隐私针对随机观察者得到保护；合规审查则不会。
-- **标准地址透明度。** 针对地址级别流（制裁检查、资金来源分析）运行的 AML/KYC 工具，与任何透明链使用相同的公共地址图。
+- **确定性审计员访问。** 监管审计员持有密钥，可以解密其管辖范围内交易的屏蔽金额。商业隐私对随机观察者是保留的；合规审查则不然。
+- **标准地址透明度。** 对地址级别流（制裁检查、资金来源分析）进行操作的AML/KYC工具与任何透明链使用相同的公共地址图。
 
 ## 何时使用它
 
-保密转账适用于金额具有商业敏感性，但交易对手适当地公开的任何流程：
+机密传输适用于金额具有商业敏感性但交易对手方适当公开的任何流程：
 
-- 供应商和发票支付，其中订单规模会泄露定价。
-- 财务操作，其中仓位规模会泄露策略。
+- 供应商和发票支付，其中订单规模会暴露定价。
+- 财务运营，其中头寸规模会暴露策略。
 - 工资发放，其中个人薪资不应被竞争对手索引。
-- 大额场外结算，其中与订单簿信息相关的价格发现存在风险。
+- 大型OTC结算，其中针对订单簿磁带的价格发现是风险。
 
-对于也需要地址级别隐私的流程（例如举报人捐款），仅靠保密转账是不够的。这些用例需要 Stable 不提供的额外地址模糊原语。
+对于也需要地址级别隐私的流程（例如举报人捐款），仅靠机密传输是不够的。这些用例需要Stable不提供的额外地址混淆原语。
 
 ## 状态
 
-保密转账正在开发中。有关时间安排，请参阅[路线图](/cn/explanation/technical-roadmap)。该机制将作为标准 USDT0 转账的专用转账路径推出；未选择加入的现有应用程序不受影响。
+机密传输正在开发中。有关时间安排，请参阅[路线图](/cn/explanation/technical-roadmap)。该机制将作为专用传输路径与标准USDT0传输一起发布；未选择加入的现有应用程序不受影响。
 
-## 推荐阅读
+## 下一步建议
 
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解保密转账所保护的资产模型。
-- [**资金流向**](/cn/explanation/flow-of-funds)：了解保密性在端到端支付生命周期中的作用。
-- [**路线图**](/cn/explanation/technical-roadmap)：追踪保密转账的发布时间。
+- [**USDT0 作为燃料代币**](/cn/explanation/usdt-as-gas-token)：了解机密传输所屏蔽的资产模型。
+- [**资金流向**](/cn/explanation/flow-of-funds)：了解保密性在端到端支付生命周期中的位置。
+- [**路线图**](/cn/explanation/technical-roadmap)：跟踪机密传输的发布时间。
diff --git a/docs/pages/cn/explanation/eip-7702.mdx b/docs/pages/cn/explanation/eip-7702.mdx
@@ -1,53 +1,53 @@
 ---
 source_path: explanation/eip-7702.mdx
-source_sha: 599d3ed0fdc99452166ebb51a8d74932622954f6
+source_sha: 4d8d9eeda07972e9238453bf7a50962d467f6722
 title: "EIP-7702"
-description: "EOA 的批量支付、消费限额和会话密钥，无需新建账户或钱包迁移。"
+description: "EOA 的批量支付、消费限额和会话密钥，无需新的账户或钱包迁移。"
 diataxis: "explanation"
 ---
 
 # EIP-7702
 
-Stable 支持 **EIP-7702**，它允许 EOA **将其账户代码设置为现有智能合约**。EOA 执行该合约的逻辑，同时保留其原始地址和私钥。委托是持久的，直到 EOA 明确更改或清除它。
+Stable 支持 **EIP-7702**，它允许 EOA **将其账户代码设置为现有的智能合约**。EOA 执行该合约的逻辑，同时保留其原始地址和私钥。委托是持久的，直到 EOA 明确更改或清除它。
 
-有关完整规范，请参阅 [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)。
+有关完整规范，请参见 [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)。
 
-## EIP-7702 在 Stable 上实现了什么
+## EIP-7702 在 Stable 上实现的功能
 
-EIP-7702 允许现有 EOA 执行智能合约逻辑，而无需账户迁移。在 Stable 以 USDT 为中心的支付环境中，这支持以下模式：
+EIP-7702 允许现有 EOA 执行智能合约逻辑，无需账户迁移。在 Stable 以 USDT 为中心的支付环境中，这支持以下模式：
 
-- **批量支付**: 多个调用（例如，在一个工资支付周期中向多个收款人支付）在一个原子交易中执行。
-- **消费限额**: 委托合约对 EOA 强制执行每日上限或每笔交易限额。
-- **会话密钥**: EOA 向 dApp 授予范围受限、有时效的交易权限，而无需暴露所有者的私钥。
+- **批量支付**：多个调用（例如，在一个工资支付周期中向多个接收方支付）在一个原子交易中执行。
+- **消费限额**：委托合约对 EOA 强制执行每日上限或每笔交易限额。
+- **会话密钥**：EOA 授予 DApp 范围化的、有时间限制的交易权限，而无需暴露所有者的私钥。
 
 :::note
-**准备好实施了吗？** 请参阅 [账户抽象 (EIP-7702) 实施指南](/cn/reference/eip-7702-api)，了解合约模板、授权签名和交易提交。
+**准备实施？** 请参阅[账户抽象 (EIP-7702) 实施指南](/cn/reference/eip-7702-api)，了解合约模板、授权签名和交易提交。
 :::
 
 ## 工作原理
 
-EIP-7702 引入了一种新的交易类型 (`0x04`)，它带有一个 `authorizationList`。每个授权指定一个智能合约，EOA 将为该交易执行该合约的代码。流程如下：
+EIP-7702 引入了一种新的交易类型 (`0x04`)，它带有一个 `authorizationList`。每个授权都指定一个智能合约，EOA 将在该交易中执行该合约的代码。流程如下：
 
-1. **选择或部署委托合约**: 一个标准的 Solidity 合约，实现了您希望 EOA 运行的逻辑。您可以使用现有的已部署合约或部署您自己的合约。尽可能使用经过审计的合约。
-2. **签署授权**: EOA 所有者签署一条消息，指定委托合约。
-3. **提交 EIP-7702 交易**: 交易包含授权，EOA 在执行期间运行委托的代码。
+1. **选择或部署委托合约**：一个标准的 Solidity 合约，实现了您希望 EOA 运行的逻辑。您可以使用现有已部署的合约或部署自己的合约。尽可能使用经过审计的合约。
+2. **签署授权**：EOA 所有者签署一条消息，指定委托合约。
+3. **提交 EIP-7702 交易**：交易包含授权，EOA 在执行期间运行委托的代码。
 
-提交后，EOA 的账户代码被设置为委托。随后的 EOA 交易将执行委托的逻辑，直到所有者清除或替换委托。
+提交后，EOA 的账户代码被设置为委托。随后的 EOA 交易执行委托的逻辑，直到所有者清除或替换委托。
 
 ## 不变之处
 
-- **无需新账户**: 用户保留其现有的 EOA 地址和私钥。没有迁移步骤。
-- **现有密钥仍然签名**: EOA 的私钥对授权和任何后续交易进行签名。EIP-7702 没有引入新的签名方案。
-- **标准 EVM 执行**: 委托作为常规合约代码运行。调试或跟踪合约执行的工具保持不变。
+- **无需新账户**：用户保留其现有的 EOA 地址和私钥。没有迁移步骤。
+- **现有密钥仍可签名**：EOA 的私钥签署授权和任何后续交易。EIP-7702 不引入新的签名方案。
+- **标准 EVM 执行**：委托作为常规合约代码运行。调试或跟踪合约执行的工具无需更改即可工作。
 
 ## 安全考虑
 
-- **委托访问是全面的。** 在委托期间，委托合约对 EOA 拥有完全执行权限。将委托选择视为信任决策：恶意委托可能会耗尽资产。
-- **委托是持久的。** 它不会在单笔交易结束时过期。当所有者不再需要时，必须明确清除或替换委托。
-- **Gas 成本略高**，这是由于授权处理，但在委托批量处理多个调用时可以抵消。在 Stable 上，基础费用为 1 gwei，gas 以 USDT0 计价，额外的授权开销远低于一美分，与标准 ERC-20 传输的成本相当。
+- **委托访问是全面的。** 委托合约在委托期间对 EOA 拥有完全的执行权限。将委托选择视为信任决策：恶意委托可能会耗尽资产。
+- **委托是持久的。** 它不会在单次交易结束后过期。当所有者不再需要它时，必须明确清除或替换委托。
+- **Gas 成本略高** 由于授权处理，但这在委托批量处理多个调用时得到抵消。在 Stable 上，基础费用为 1 gwei 且 gas 以 USDT0 计价，额外的授权开销远低于一美分，与标准 ERC-20 转账成本相当。
 
-## 接下来推荐
+## 下一步建议
 
-- [**账户抽象 (EIP-7702)**](/cn/reference/eip-7702-api)：针对委托合约实施批量支付、消费限额和会话密钥。
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 EIP-7702 交易运行的 Gas 模型。
-- [**Gas 豁免**](/cn/explanation/gas-waiver)：将委托与应用程序代替用户支付 Gas 的 Gas 豁免流程进行比较。
+- [**账户抽象 (EIP-7702)**](/cn/reference/eip-7702-api)：针对委托合约实现批量支付、消费限额和会话密钥。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 EIP-7702 交易运行的 Gas 模型。
+- [**Gas 免除**](/cn/explanation/gas-waiver)：将委托与应用程序为用户支付 Gas 的 Gas 免除流程进行比较。