diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md
index 390e613..6be9a92 100644
--- 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
index a9c8470..b06d336 100755
--- 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
index a9ae3e4..6a0d1c9 100755
--- 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
index 3db884e..c853450 100755
--- 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 免除流程进行比较。
diff --git a/docs/pages/cn/explanation/erc-3009.mdx b/docs/pages/cn/explanation/erc-3009.mdx
index 1fdb456..29cda00 100644
--- a/docs/pages/cn/explanation/erc-3009.mdx
+++ b/docs/pages/cn/explanation/erc-3009.mdx
@@ -1,98 +1,98 @@
---
source_path: explanation/erc-3009.mdx
-source_sha: 355aa51b2e83bc01b1345eb0ec5d437956854d01
+source_sha: b8359b8c523fa0b88e18a1672228e6cd45f59dfc
title: "使用签名授权进行结算"
-description: "通过签署消息来授权代币转账，无需直接调用合约。ERC-3009 是 Stable 上 x402 支付的结算机制。"
+description: "通过签名消息授权代币转账，无需直接调用合约。ERC-3009 是 Stable 上 x402 支付背后的结算机制。"
diataxis: "explanation"
---
# 使用签名授权进行结算
-ERC-3009 允许代币持有者通过签署消息来授权转账。任何人都可以提交该签名授权以在链上执行转账。发送者无需直接调用合约。
+ERC-3009 允许代币持有者通过签名消息来授权转账。任何人都可以在链上提交该签名授权来执行转账。发送方无需直接调用合约。
-这是 Stable 上 [x402](/cn/explanation/x402) 支付的结算机制。
+这是 Stable 上 [x402](/cn/explanation/x402) 支付背后的结算机制。
-## 解决了什么问题？
+## 它解决了什么问题？
-### 授权问题
+### 额度问题
-ERC-20 传统第三方转账模式是 `approve` + `transferFrom`。发送者首先调用 `approve` 授予消费额度，然后第三方调用 `transferFrom` 转移资金。这存在众所周知的问题：
+传统上，ERC-20 第三方转账的模式是 `approve` + `transferFrom`。发送方首先调用 `approve` 授权销费额度，然后第三方调用 `transferFrom` 转移资金。这存在一些众所周知的问题：
-- **需要两笔交易**：发送者在任何转账发生之前必须发送一笔链上 `approve` 交易。这会产生 gas 费用并增加延迟。
-- **无限授权风险**: 为了避免重复的授权交易，许多应用程序请求无限消费权限，这带来了重大的安全风险。
+- **需要两次交易**：发送方必须在任何转账发生之前发送一笔链上 `approve` 交易。这会消耗 Gas 并增加延迟。
+- **无限额度风险**：为避免重复的授权交易，许多应用程序会请求无限支出权限，这会带来重大的安全风险。
-ERC-3009 采取了不同的方法。发送者不是授予额度，而是签署一次性授权，用于特定转账。没有单独的批改步骤，也没有遗留的消费权限。
+ERC-3009 采用了不同的方法。发送方不是授予额度，而是为特定转账签署一次性授权。没有单独的批准步骤，也没有长期存在的支出权限。
-### 顺序 Nonce 问题
+### 连续随机数问题
-ERC-2612 (`permit`) 也支持签名授权，但它使用顺序 Nonce。多个 permit 具有排序依赖性：如果 Nonce 5 未被消耗，Nonce 6 将永远无法执行。
+ERC-2612 (`permit`) 也支持签名授权，但它使用连续的随机数。多个许可存在排序依赖性：如果随机数 5 未被消耗，则随机数 6 永远无法执行。
-ERC-3009 通过 **唯一 Nonce** 解决了这个问题。每个授权使用 32 字节的值，而不是顺序计数器。多个授权可以独立创建和提交，以任何顺序，互不依赖。
+ERC-3009 通过**唯一随机数**解决了这个问题。每个授权都使用一个 32 字节的值，而不是连续计数器。可以独立创建和提交多个授权，以任何顺序，互不依赖。
### 比较
| **属性** | **ERC-20** (`approve`) | **ERC-2612** (`permit`) | **ERC-3009** |
| :--- | :--- | :--- | :--- |
| 链上步骤 | 2 (`approve` + `transferFrom`) | 1 (`transferFrom`) | 1 (`transferWithAuthorization`) |
-| 使用授权模型 | 需要（链上交易） | 是（通过 `permit` 设置授权） | 不需要（签名） |
-| Nonce 模型 | 顺序 | 顺序 | 唯一 |
+| 使用额度模型 | 需要（链上交易） | 是（通过 `permit` 设置额度） | 不需要（签名） |
+| 随机数模型 | 连续 | 连续 | 唯一 |
| 并发授权 | 否 | 否 | 是 |
## 工作原理
### transferWithAuthorization
-发送者签署一个包含转账详情的 EIP-712 类型数据消息。然后任何人都可以用该签名消息调用代币合约上的 `transferWithAuthorization`。合约验证签名，检查有效期窗口，执行转账，并将 Nonce 标记为已使用。
+发送方签署EIP-712类型数据消息，其中包含转账详情。任何人都可以使用该签名消息在代币合约上调用 `transferWithAuthorization`。合约验证签名，检查有效期窗口，执行转账，并标记随机数为已使用。
签名授权包含：
-- `from`：发送者（签名者）的地址
-- `to`：接收者的地址
+- `from`：发送方（签名者）的地址
+- `to`：接收方的地址
- `value`：转账金额
- `validAfter`：此授权可执行的最早时间（Unix 时间戳）
- `validBefore`：此授权可执行的最晚时间（Unix 时间戳）
- `nonce`：确保唯一性的 32 字节值
-时间窗口（`validAfter`/`validBefore`）使发送者能够精确控制转账何时发生。授权可以安排在未来、给定截止日期或两者兼有。如果窗口在提交前过期，则授权无效，资金仍归发送者所有。
+时间窗口 (`validAfter`/`validBefore`) 使发送方能够精确控制转账发生的时间。授权可以安排在未来，设置截止日期，或两者兼有。如果窗口在提交前过期，则授权将失效，资金将保留在发送方手中。
### receiveWithAuthorization
-此函数的工作方式与 `transferWithAuthorization` 完全相同，但有一个额外检查：**调用者必须是接收者**。这可以防止抢先攻击，即第三方观察到待处理的授权并首先提交以操纵交易顺序。
+此函数与 `transferWithAuthorization` 完全相同，但增加了一个额外的检查：**调用者必须是接收方**。这可以防止抢先交易攻击，即第三方观察到待处理的授权并首先提交它以操纵交易顺序。
-这在支付场景中很有用，其中接收者（商家或服务提供商）应该是发起结算的一方。
+这在支付场景中非常有用，例如商家或服务提供商应发起结算。
### cancelAuthorization
-发送者可以在授权执行之前撤销未使用的授权。发送者签署一个 EIP-712 取消消息，合约将 Nonce 标记为已使用而不执行转账。原始授权将不再可提交。
+发送方可以在未执行之前撤销未使用的授权。发送方签署 EIP-712 取消消息，合约标记随机数为已使用，而不执行转账。原始授权不能再被提交。
-## 内置安全属性
+## 内置安全特性
-- **一次性使用**：每个唯一的 Nonce 只能使用一次。重新提交相同的签名授权将回滚。
-- **有时限**：`validAfter`/`validBefore` 窗口确保授权不会无限期有效。
-- **自包含**：一个签名授权一次特定转账给一个特定接收者，用于一个特定金额。没有遗留权限。
-- **非托管**：提交者从不持有发送者的资金。转账直接在合约内从发送者转移到接收者。
+- **一次性使用**：每个唯一的随机数只能使用一次。重新提交相同的签名授权将导致回滚。
+- **有时效性**：`validAfter`/`validBefore` 窗口确保授权不会无限期有效。
+- **自包含**：一个签名授权一次特定的转账到特定的接收方，金额特定。没有长期存在的权限。
+- **非托管**：提交者从不持有发送方的资金。转账直接在合约内从发送方转移到接收方。
## Stable 上的 ERC-3009
-Stable 上的 USDT0 原生实现了 ERC-3009。任何应用程序都可以使用 `transferWithAuthorization`，无需部署额外的合约或中继基础设施。
+Stable 上的 USDT0 本身实现了 ERC-3009。任何应用程序都可以使用 `transferWithAuthorization`，无需部署额外的合约或中继基础设施。
### 单资产结算
-在以太坊上，即使使用 ERC-3009，提交者也需要 ETH 来支付调用 `transferWithAuthorization` 的 gas 费。转账本身是以 USDT 进行的，但执行取决于单独的原生资产。
+在以太坊上，即使使用 ERC-3009，提交者仍需要 ETH 来支付调用 `transferWithAuthorization` 的 Gas 费。转账本身是以 USDT 进行的，但执行依赖于单独的原生资产。
-在 Stable 上，USDT0 既是支付代币也是 gas 代币。从授权到链上结算的整个支付生命周期都在单一稳定币上运行。在任何步骤都不需要单独的原生资产。
+在 Stable 上，USDT0 既是支付代币，又是 Gas 代币。从授权到链上结算的整个支付生命周期都在一个稳定币上运行。任何步骤都不需要单独的原生资产。
-这一特性使得 Stable 上的 ERC-3009 成为更高级别支付协议的坚实基础。[x402](/cn/explanation/x402) 直接利用了这一点，使用 ERC-3009 作为其在标准 HTTP 通信中的链上结算机制。
+这一特性使得 Stable 上的 ERC-3009 成为更高级别支付协议的强大基础。[x402](/cn/explanation/x402) 直接利用了这一点，将 ERC-3009 作为其在标准 HTTP 通信中的链上结算机制。
-## 主要观点
+## 主要收获
-- ERC-3009 允许代币持有者通过签名消息授权转账。任何人都可以提交该签名授权以执行转账。
-- 它用一次性、自包含的授权取代了 ERC-20 授权模型。没有 `approve` 步骤，没有遗留权限，没有双重支付风险。
-- 唯一 Nonce 允许并发创建和提交多个授权，以任何顺序。
-- Stable 上的 USDT0 原生支持 ERC-3009，并且由于结算可以仅使用 USDT0 完成，它为 x402 提供了实用的基础。
+- ERC-3009 允许代币持有者通过签名消息授权转账。任何人都可以提交该签名授权来执行转账。
+- 它用一次性、自包含的授权取代了 ERC-20 额度模型。没有 `approve` 步骤，没有长期存在的权限，也没有重复花费的风险。
+- 独特的随机数允许同时创建和提交多个授权，顺序不限。
+- Stable 上的 USDT0 原生支持 ERC-3009，并且由于仅使用 USDT0 即可完成结算，它为 x402 提供了实用的基础。
**另请参阅：**
-- [USDT 作为 Gas](/cn/explanation/usdt-as-gas-token)
+- [USDT0 作为 Gas](/cn/explanation/usdt-as-gas-token)
- [USDT0 在 Stable 上的行为](/cn/explanation/usdt0-behavior)
- [x402 (HTTP 原生支付)](/cn/explanation/x402)
diff --git a/docs/pages/cn/explanation/ethereum-comparison.mdx b/docs/pages/cn/explanation/ethereum-comparison.mdx
index 5228994..1addff4 100644
--- a/docs/pages/cn/explanation/ethereum-comparison.mdx
+++ b/docs/pages/cn/explanation/ethereum-comparison.mdx
@@ -1,6 +1,6 @@
---
source_path: explanation/ethereum-comparison.mdx
-source_sha: 899ef035bfd583ce5d1f14916e2dbd9df613a7bb
+source_sha: a54f9794aff02779e52e91631c6447116a7800a4
title: "以太坊对比"
description: "Stable 完全兼容 EVM。在从以太坊移植时，哪些保持不变，哪些会改变，以及需要注意什么。"
diataxis: "explanation"
@@ -8,7 +8,7 @@ diataxis: "explanation"
# 以太坊对比
-Stable 完全兼容 EVM，因此大多数以太坊工具、库和合约模式都无需修改即可使用。以下部分将介绍从以太坊迁移到 Stable 时哪些保持不变，哪些会改变。
+Stable 完全兼容 EVM，因此大多数以太坊工具、库和合约模式无需修改即可正常工作。以下部分将介绍从以太坊迁移到 Stable 时哪些保持不变，哪些会改变。
## 保持不变的地方
@@ -22,60 +22,60 @@ Stable 保持与以太坊开发生态系统的完全兼容：
| 合约模式 | 所有标准 EVM 约定 (ERC-20, ERC-721, ERC-1155, 代理等) |
| RPC 接口 | 支持大多数 `eth_*` 方法 (`eth_call`, `eth_sendRawTransaction`, `eth_getBalance`, `eth_getLogs`, `eth_estimateGas` 等)。有关完整列表，请参阅 [JSON-RPC API](/cn/reference/json-rpc-api) |
-通过更改 RPC 端点和链 ID，现有的智能合约、部署脚本和前端集成可以目标 Stable。
+现有的智能合约、部署脚本和前端集成通过更改 RPC 端点和链 ID 来针对 Stable。
## 不同之处
有四种行为与以太坊不同。
-### 1. 单槽最终性
+### 1. 单槽终结性
-以太坊需要多次区块确认才能认为交易最终确定。Stable 提供单槽最终性：交易一旦包含在区块中即为最终确定。
+以太坊需要多次区块确认才能认为交易最终确定。Stable 提供单槽终结性：一旦交易包含在区块中，它就是最终的。
-对于开发人员而言，这意味着：
+对于开发者而言，这意味着：
-- 一旦交易出现在已确认的区块中，其状态变化就是最终且不可逆的。
+- 一旦交易出现在已确认的区块中，其状态变化即为最终且不可逆转。
- 应用程序可以安全地依赖区块包含作为结算确认。
-即使是确定性最终性，处理金融敏感流的应用程序也应该：
+即使具有确定性终结性，处理金融敏感流的应用程序仍应：
-- 在执行依赖操作（例如，解锁、赎回）之前，通过 RPC 或发出的事件验证交易是否成功。
-- 为自动化和批量操作实施重试和协调逻辑，以处理瞬时提交或 RPC 错误。
+- 在进行依赖操作（例如解锁、赎回）之前，通过 RPC 或发出的事件验证交易成功。
+- 为自动化和批处理操作实施重试和协调逻辑，以处理瞬时提交或 RPC 错误。
### 2. Gas 代币：USDT0
-在 Stable 上，交易费用以 USDT0 支付，而不是波动性原生代币。这提供以 USDT 计价的、可预测的低 Gas 成本。
+在 Stable 上，交易费用以 USDT0 支付，而不是波动的原生代币。这提供了以 USDT 计价的、可预测的低 Gas 成本。
- 用户钱包中需要有 USDT0 才能提交交易。
-- 交易中的 `value` 字段仍然可以用于发送 USDT0，类似于以太坊上发送 ETH 的方式。
-- 详情请参阅 [以 USDT 作为 Gas](/cn/explanation/usdt-as-gas-token)。
+- 交易中的 `value` 字段仍可用于发送 USDT0，类似于以太坊上发送 ETH 的方式。
+- 有关详细信息，请参阅 [USDT0 作为 Gas](/cn/explanation/usdt-as-gas-token)。
-### 3. 没有优先级小费
+### 3. 无优先费用 (priority tips)
-Stable 使用单一组件 Gas 模型。没有基于小费的交易排序。
+Stable 使用单组件 Gas 模型。没有基于小费的交易排序。
- `maxPriorityFeePerGas` 被忽略（始终为 0）。
- 交易排序不受费用竞价影响。
-- 钱包应隐藏或禁用优先级小费输入字段。
-- 详情请参阅 [Gas 定价](/cn/explanation/gas-pricing)。
+- 钱包应隐藏或禁用优先费用输入字段。
+- 有关详细信息，请参阅 [Gas 定价](/cn/explanation/gas-pricing)。
### 4. USDT0 双重角色行为
-USDT0 既充当原生 Gas 代币，又充当 ERC-20 代币。这导致在余额语义、许可安全性和某些操作码假设方面存在行为差异。有关完整详细信息，请参阅 [Stable 上的 USDT0 行为](/cn/explanation/usdt0-behavior)。
+USDT0 既是原生 Gas 代币，又是 ERC-20 代币。这引入了围绕余额语义、代币授权安全性以及某些操作码假设的行为差异。有关完整详细信息，请参阅 [Stable 上的 USDT0 行为](/cn/explanation/usdt0-behavior)。
## 快速比较
| **参数** | **Stable** | **以太坊** |
| :--- | :--- | :--- |
| Gas 代币 | USDT0 | ETH |
-| 最终性 | 单槽 | 多区块确认 |
-| 区块时间 | ~0.7 秒 | ~12 秒 |
-| 优先级小费 (`maxPriorityFeePerGas`) | 忽略 (始终为 0) | 用于排序 |
+| 终结性 | 单槽 | 多区块确认 |
+| 出块时间 | ~0.7 秒 | ~12 秒 |
+| 优先费用 (`maxPriorityFeePerGas`) | 被忽略（始终为 0） | 用于排序 |
| EIP-1559 交易格式 | 支持 | 支持 |
| EVM 兼容性 | 完全 | 不适用 |
-## 推荐阅读
+## 建议下一步
-- [**以 USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解用于替代 ETH 作为 Gas 的资产模型。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解替代 ETH 作为 Gas 的资产模型。
- [**Gas 定价**](/cn/explanation/gas-pricing)：详细审查单组件费用模型。
-- [**Stable 上的 USDT0 行为**](/cn/explanation/usdt0-behavior)：审计合约以了解双重角色资产语义、许可安全性和 `EXTCODEHASH` 行为。
+- [**Stable 上的 USDT0 行为**](/cn/explanation/usdt0-behavior)：审计合约，检查双重角色资产语义、代币授权安全性和 `EXTCODEHASH` 行为。
diff --git a/docs/pages/cn/explanation/flow-of-funds.mdx b/docs/pages/cn/explanation/flow-of-funds.mdx
index ae9c881..9a8afae 100644
--- a/docs/pages/cn/explanation/flow-of-funds.mdx
+++ b/docs/pages/cn/explanation/flow-of-funds.mdx
@@ -1,67 +1,67 @@
---
source_path: explanation/flow-of-funds.mdx
-source_sha: cfc1ee60f37976af8099cec9efcea804bfab0f15
-title: "资金流"
+source_sha: a5cf76cc30ee47cc0f9e164a9419bf68d2e388ac
+title: "资金流转"
description: "USDT 在 Stable 上的端到端生命周期，从入金到链上转账再到出金结算。"
diataxis: "explanation"
---
-# 资金流
+# 资金流转
-Stable 是第一个专为稳定币支付而构建的区块链。该网络针对高吞吐量、低延迟的稳定币交易进行了优化，通过 USDT 提供即时结算的 P2P 支付和商家受理。应用层 Gas 赞助和豁免让提供商能够为终端用户提供零费用体验，提供主流支付网络的感受，同时抽象化区块链系统的复杂性。
+Stable 是第一个专门为稳定币支付而构建的区块链。该网络针对高吞吐量、低延迟的稳定币交易进行了优化，提供 P2P 支付和商家B端接收，并以 USDT 进行即时结算。应用层 Gas 代付和免除允许提供商为最终用户提供零费用体验，提供主流支付网络的感受，同时抽象出区块链系统的复杂性。
-本页描述了 Stable 上资金的完整生命周期：USDT 如何进入网络、在参与者之间移动以及退回到法币通道。
+本页面描述了 Stable 上资金的完整生命周期：USDT 如何进入网络，如何在参与者之间移动，以及如何退回到法币通道。
-## 1. 客户存款（入金）
+## 1. 客户入金（on-ramp）
用户通过以下三种主要渠道之一将资金引入网络：
-- **加密货币转账**：任何主要的加密货币通过跨链桥接或转换为 Stable 上的 USDT0。USDT0 是 USDT 的全链标准，也是网络上的主要形式。
-- **法币入金**：通过银行卡、ACH 或本地支付方式将法币转换为 USDT0，直接存入用户钱包。
-- **CEX 提现**：用户从支持的中心化交易所提取 USDT，选择 Stable 作为目标网络。交易所直接结算到用户钱包。
+- **加密货币转账**：任何主要的加密货币通过跨链桥或转换，变成 Stable 上的 USDT0。USDT0 是 USDT 的全链标准，也是网络上的主要形式。
+- **法币入金**：银行卡、ACH 或当地支付方式将法币转换为 USDT0，直接发送到用户的钱包。
+- **CEX 提款**：用户从支持的中心化交易所提取 USDT，选择 Stable 作为目标网络。交易所直接结算到用户的钱包。
-在所有情况下，最终状态都是相同的：用户的钱包直接在 Stable 上持有 USDT (以 USDT0 形式)。
+在所有情况下，最终状态都是相同的：用户的钱包直接在 Stable 上持有 USDT（作为 USDT0）。
## 2. P2P / 商家转账（链上支付）
-资金一旦进入 Stable，客户就可以直接将 USDT 发送给另一个用户或商家。链上转账的关键特性：
+资金一旦进入 Stable，客户就可以直接将 USDT 发送给其他用户或商家。链上转账的关键特性包括：
-- **即时结算**：转账在链上即时结算。
-- **非托管**：在非托管钱包的情况下，在源地址和目标地址之间，没有任何支付服务提供商 (PSP) 或中介接触用户余额。
-- **单一资产**：由于 USDT 既是 Gas 也是结算资产，流程中没有额外的代币，也没有 скрытое 点差。
-- **零 Gas 选项**：Gas 豁免允许终端用户转移资金，而无需管理区块链费用。详情请参阅 [Gas 豁免](/cn/reference/gas-waiver-api)。
+- **即时结算**：转账立即在链上结算。
+- **非托管**：在非托管钱包的情况下，在源地址和目标地址之间，没有支付服务提供商或中间商触及用户余额。
+- **单一资产**：由于 USDT 既是 Gas 又是结算资产，因此流程中没有额外的代币，也没有隐藏的差价。
+- **零 Gas 选项**：Gas 免除允许最终用户无需管理区块链费用即可转移资金。详见 [Gas 代付](/cn/reference/gas-waiver-api)。
## 3. 用户 / 商家余额
-商家在自己的直接控制下，在他们的 Stable 钱包中接收 USDT。资金以用户或商家托管的方式在链上持有。这些钱包可以由支付提供商代表用户创建和管理。
+商家在自己的直接控制下，TUSDT 会存入他们的 Stable 钱包。资金在链上由用户或商家保管。这些钱包可以由支付服务提供商代表用户创建和管理。
-## 4. 商家提现（出金 / 付款）
+## 4. 商家提款（off-ramp / payout）
当商家或用户请求链下法币结算时：
1. 提供商通过银行或支付通道发起转换（USDT → 法币）。
2. 资金存入商家选择的账户。
-提供商只在商家提现时重新进入流程，而不是在生态系统内部转账期间。日常 P2P 流程不需要中介；提供商只参与存款（USDT 转账到商家账户）或提现（USDT → 法币）。
+提供商只在商家提现时重新介入流程，而在生态系统内部转账时则不介入。日常 P2P 流程无需中介；提供商只参与入金（USDT 转账到商家账户）或提款（USDT → 法币）。
## 跨资产交易
-Stable 还支持付款方持有非 USDT 加密货币的场景。
+Stable 还支持付款人持有非 USDT 加密货币的场景。
### 用户交易为其他加密货币
-用户可以通过集成交易所、经纪商或链上 DEX 持有或交易其他加密货币（例如 BTC 或 ETH）。在支付时，系统会自动将所选加密货币转换为 USDT，然后传输到商家的 Stable 钱包。无论用户偏好的资产是什么，所有链上结算都继续以 USDT 进行。
+用户可以通过集成交易所、经纪商或链上 DEX 持有或交易为其他加密货币（例如 BTC 或 ETH）。在支付时，系统会自动将选定的加密货币转换为 USDT，然后传输到商家的 Stable 钱包。无论用户偏好的资产是什么，所有链上结算都继续以 USDT 进行。
### 商家接受加密货币支付
-商家无需直接接受或管理多种加密货币。他们的 Stable 钱包中始终记入 USDT，从而在整个网络中保持单一结算货币。这种设计最大限度地降低了商家的外汇风险，并简化了对账和报告。
+商家无需直接接受或管理多种加密货币。他们总是在 Stable 钱包中获得 USDT，从而在整个网络中保持单一的结算货币。这种设计最大限度地降低了商家的外汇风险，并简化了对账和报告。
-### 提供商在转换中的作用
+### 提供商在转换中的角色
-转换逻辑（例如，BTC → USDT）可以由交易所合作伙伴、流动性提供商或支付提供商自己的财务部门处理。商家不受波动性或流动性风险的影响；他们只接收 USDT。
+转换逻辑（例如 BTC → USDT）可以由交易所合作伙伴、流动性提供商或支付服务提供商自己的资金管理。商家免受波动性或流动性风险的影响；他们只接收 USDT。
-## 下一步建议
+## 下一步推荐
-- [**将 USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 USDT0 如何在 Stable 上同时作为原生 Gas 和 ERC-20 余额。
-- [**将 USDT0 桥接到 Stable**](/cn/explanation/usdt0-bridging)：了解 USDT0 如何通过 OFT Mesh 或 Legacy Mesh 从其他链桥接到 Stable。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 USDT0 如何在 Stable 上既作为原生 Gas 又作为 ERC-20 余额。
+- [**将 USDT0 桥接到 Stable**](/cn/explanation/usdt0-bridging)：了解 USDT0 如何通过 OFT Mesh 或 Legacy Mesh 从其他链转移到 Stable。
- [**发送您的第一笔 USDT0**](/cn/tutorial/send-usdt0)：使用标准 EVM 工具在测试网上提交 USDT0 转账。
diff --git a/docs/pages/cn/explanation/gas-pricing.mdx b/docs/pages/cn/explanation/gas-pricing.mdx
index f6d5d24..78d42dc 100755
--- a/docs/pages/cn/explanation/gas-pricing.mdx
+++ b/docs/pages/cn/explanation/gas-pricing.mdx
@@ -1,22 +1,22 @@
---
source_path: explanation/gas-pricing.mdx
-source_sha: cee955370fcdfb739edadd48366ac6c984cbc9d9
-title: "Gas 费用"
-description: "Stable 采用单一组件的 Gas 费模型，没有优先级小费，以 USDT0 计价提供可预测的成本。"
+source_sha: 2f2ac159d9c7941aebcab3ae1fe43a666140e868
+title: "Gas 定价"
+description: "Stable 采用单一组件燃气费模型，没有优先小费，提供以 USDT0 计价的可预测成本。"
diataxis: "explanation"
---
-# Gas 费用
+# Gas 定价
-Stable 采用简化的单一组件 Gas 费模型，旨在消除费用波动并提供可预测的低交易成本。交易排序不受小费竞价的影响。有效的 Gas 价格仅由协议的基础费用决定。
+Stable 采用简化的单一组件燃气费模型，旨在消除费用波动并提供可预测的低交易成本。交易排序不受小费竞价的影响。有效燃气价格完全由协议的基础费用决定。
-## 为什么采用此模型
+## 为什么选择此模型
-单一组件设计具有三个特点：
+单一组件设计具有三个特性：
- **可预测的成本**：费用纯粹基于基础执行成本。小费拍卖不会引入差异。
-- **USDT 计价**：Gas 以 USDT0 定价，因此开发人员或用户在考虑美元成本时不必考虑原生代币价格波动。
-- **极低的费用**：在 1 gwei 的基础费下，原生 USDT0 转账（21,000 gas）大约花费 **0.0000021 USDT0**。即使是复杂的合约交互，费用也远低于一美分。
+- **USDT 计价**：燃气以 USDT0 计价，因此开发人员或用户在以美元计价时无需考虑原生代币的价格波动。
+- **极低的费用**：在基础费用为 1 gwei 时，原生 USDT0 转账（21,000 gas）成本约为 **0.0000021 USDT0**。即使是复杂的合约交互，费用也远低于一美分。
## 与以太坊的比较
@@ -24,19 +24,19 @@ Stable 采用简化的单一组件 Gas 费模型，旨在消除费用波动并
| :--- | :--- | :--- |
| Gas 代币 | USDT0 | ETH |
| 基础费用 | 是 | 是 |
-| 优先级小费 (`maxPriorityFeePerGas`) | 被忽略（始终为 0） | 用于排序 |
+| 优先小费 (`maxPriorityFeePerGas`) | 忽略（始终为 0） | 用于排序 |
| EIP-1559 交易格式 | 支持 | 支持 |
-Stable 接受 EIP-1559 (Type 2) 交易，但 `maxPriorityFeePerGas` 总是被忽略。交易排序不受小费竞价的影响。
+Stable 接受 EIP-1559（Type 2）交易，但 `maxPriorityFeePerGas` 始终被忽略。交易排序不受小费竞价的影响。
## 影响
-- **钱包**应隐藏或禁用优先级小费输入字段。显示它们可能会让用户感到困惑，因为该值无效。
-- **分析仪表盘**不应跟踪优先级费用。它们将始终为零。
-- **交易构建工具**应明确将 `maxPriorityFeePerGas` 设置为 `0`，然后从最新区块的基础费用计算 `maxFeePerGas`，并保留一个安全边际。
+- **钱包**应隐藏或禁用优先小费输入字段。显示它们可能会让用户感到困惑，因为该值无效。
+- **分析仪表板**不应跟踪优先费用。它们将始终为零。
+- **交易构建工具**应将 `maxPriorityFeePerGas` 明确设置为 `0`，然后根据最新区块的基础费用计算 `maxFeePerGas`，并留出安全边际。
## 接下来推荐
-- [**Gas 费用参考**](/cn/reference/gas-pricing-api)：根据 Stable 的费用模型构建交易、估算 Gas 并配置工具。
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 USDT0 如何同时充当原生 Gas 和 ERC-20 余额。
-- [**以太坊比较**](/cn/explanation/ethereum-comparison)：审查从以太坊移植时将遇到的所有行为差异。
+- [**Gas 定价参考**](/cn/reference/gas-pricing-api)：根据 Stable 的费用模型构建交易、估算 gas 并配置工具。
+- [**USDT0 作为 gas**](/cn/explanation/usdt-as-gas-token)：了解 USDT0 如何同时充当原生 gas 和 ERC-20 余额。
+- [**以太坊比较**](/cn/explanation/ethereum-comparison)：查看从以太坊移植时会遇到的所有行为差异。
diff --git a/docs/pages/cn/explanation/gas-waiver.mdx b/docs/pages/cn/explanation/gas-waiver.mdx
index 20389de..4cfa789 100755
--- a/docs/pages/cn/explanation/gas-waiver.mdx
+++ b/docs/pages/cn/explanation/gas-waiver.mdx
@@ -1,61 +1,61 @@
---
source_path: explanation/gas-waiver.mdx
-source_sha: 7995b37c002721e3b84297b0e4c3ba54281c0d14
-title: "Gas 费用减免"
-description: "Gas 费用减免让应用程序为用户支付 Gas 费。经治理批准的费用减免通过提交封装交易来执行已签名的有效载荷，且 Gas 价格为零。"
+source_sha: a03f510da6c1fe5ab2d31b55c8827b59792af6e0
+title: "免除Gas费"
+description: "Gas费免除机制允许应用程序为用户支付Gas费。经治理批准的豁免提交封装交易，以零Gas费运行已签名负载。"
diataxis: "explanation"
---
-# Gas 费用减免
+# 免除Gas费
-经治理批准的地址（称为**费用减免方**）提交一个封装交易，其中包含用户签名的有效载荷，并以 `gasPrice = 0` 执行。用户无需持有 USDT0，也无需支付 Gas 费。Stable 公司运营着一个这样的费用减免服务；合作伙伴也可以通过验证器治理注册自己的费用减免地址。
+经治理批准的地址（称为**豁免者**）提交一个封装交易，其中包含用户签名的负载，并以 `gasPrice = 0` 执行。用户不持有任何 USDT0 且不支付任何 Gas 费。Stable 运营着一个这样的豁免服务；合作伙伴也可以通过验证者治理注册他们自己的豁免地址。
## 工作原理
-Gas 费用减免采用封装交易模式：
+Gas费免除机制采用封装交易模式：
-1. **用户签署一个 `InnerTx`**，其中 `gasPrice = 0`。用户的签名端到端保留；费用减免方不能修改有效载荷，否则会使其失效。
-2. **费用减免方将 `InnerTx` 封装到 `WrapperTx` 中**，发送到协议标记地址 (`0x000000000000000000000000000000000000f333`)，其中 `value = 0`，`gasPrice = 0`，并将已签名的 `InnerTx` 作为其数据有效载荷。
-3. **验证器检测到标记**，检查费用减免方的授权和策略约束，并以用户身份（`from`、`nonce`、调用语义）执行内部交易。
+1. **用户签署一个 `InnerTx`**，其中 `gasPrice = 0`。用户的签名端到端保留；豁免者不能在不使其失效的情况下修改负载。
+2. **豁免者将 `InnerTx` 封装到 `WrapperTx` 中**，发送到协议标记地址 (`0x000000000000000000000000000000000000f333`)，其中 `value = 0`、`gasPrice = 0`，并将已签名的 `InnerTx` 作为其数据负载。
+3. **验证者检测到标记**，检查豁免者的授权和策略约束，并以用户的身份（`from`、`nonce`、调用语义）执行内部交易。
-Gas 记账在费用减免机制内处理。用户不支付任何费用；封装器不支付任何费用；验证器根据每个费用减免策略承担成本。
+Gas 费用核算在豁免机制内部处理。用户不支付任何费用；封装者不支付任何费用；验证者根据每个豁免者的策略承担成本。
## 授权和策略
-费用减免方由验证器治理控制，而不是应用程序逻辑。治理提供：
+豁免者由验证者治理控制，而不是应用程序逻辑。治理提供：
-- **可审查的注册**：每个费用减免地址都在链上注册，并在状态中可见。
-- **撤销**：验证器可以随时移除行为不当的费用减免方。
-- **通过 `AllowedTarget` 进行范围访问**：每个费用减免方都绑定到特定的目标合约和方法选择器集合。如果内部 `to` 地址和方法选择器超出该范围，协议将拒绝任何封装器。
+- **可审查的注册**：每个豁免地址都在链上注册并且在状态中可见。
+- **撤销**：验证者可以随时移除行为不当的豁免者。
+- **通过 `AllowedTarget` 进行范围访问**：每个豁免者都绑定到一组特定的目标合约和方法选择器。如果内部 `to` 地址和方法选择器超出该范围，协议将拒绝任何封装。
-有效的封装交易必须满足以下所有条件：
+有效的封装交易满足以下所有条件：
-- `WrapperTx.to == 0x000000000000000000000000000000000000f333`（标记地址）。
-- `WrapperTx.from` 是通过治理在链上注册的费用减免方。
-- `WrapperTx.gasPrice == 0` 和 `InnerTx.gasPrice == 0`。
-- `WrapperTx.value == 0`。
-- `InnerTx.to` 和提取的方法选择器由费用减免方的 `AllowedTarget` 策略允许。
+- `WrapperTx.to == 0x000000000000000000000000000000000000f333`（标记地址）。
+- `WrapperTx.from` 是通过治理在链上注册的豁免者。
+- `WrapperTx.gasPrice == 0` 且 `InnerTx.gasPrice == 0`。
+- `WrapperTx.value == 0`。
+- `InnerTx.to` 和提取的方法选择器由豁免者的 `AllowedTarget` 策略允许。
-如果任何条件失败，验证器将拒绝封装器，而不执行内部交易。
+如果任何条件失败，验证者将拒绝封装而不执行内部交易。
## 安全模型
-- **用户签名完整性**：用户签署 `InnerTx`。费用减免方不能修改有效载荷，否则会使签名无效。合作伙伴仍有责任确保用户只签署预期的有效载荷。
-- **链上授权**：授权存在于链上。只有治理注册的费用减免地址才能提交有效的封装，无论请求源自何处。
-- **服务可用性边界**：当合作伙伴通过 Stable 托管的费用减免服务器路由时，提交的可用性取决于服务。协议级别的授权保证不受影响。
+- **用户签名完整性**：用户签署 `InnerTx`。豁免者不能在不使签名失效的情况下修改负载。合作伙伴仍有责任确保用户只签署预期的负载。
+- **链上授权**：授权存在于链上。只有治理注册的豁免地址才能提交有效的封装，无论请求源自何处。
+- **服务可用性边界**：当合作伙伴通过 Stable 托管的豁免服务器路由时，提交的可用性取决于服务。协议级别的授权保证不受影响。
-## 何时使用 Gas 费用减免
+## 何时使用Gas费免除机制
-Gas 费用减免适用于最终用户无需持有 USDT0 来支付 Gas 费的任何流程：
+Gas费免除机制适用于任何用户不需要持有 USDT0 支付 Gas 费的场景：
-- 消费者应用程序正在引导尚未有稳定币余额的用户。
-- 代理驱动的流程，其中代理的钱包支付 Gas 费。
-- 企业支付轨道，其中运营商承担网络成本。
+- 消费者应用程序引导新用户，这些用户尚未持有稳定币余额。
+- 代理驱动的流程，其中代理的钱包支付 Gas 费。
+- 企业支付轨道，其中运营商承担网络成本。
-对于用户持有 USDT0 但希望将多个调用捆绑到一个签名交易的流程，请参阅[EIP-7702 委托](/cn/reference/eip-7702-api)。
+对于用户持有 USDT0 但希望将多个调用捆绑到一个签名交易的流程，请参阅[EIP-7702 委托](/cn/reference/eip-7702-api)代替。
-## 推荐下一步
+## 下一步建议
-- [**启用无 Gas 交易**](/cn/how-to/integrate-gas-waiver)：通过 API 密钥提交和 NDJSON 响应集成托管的费用减免服务器 API。
-- [**Gas 费用减免协议**](/cn/reference/gas-waiver-api)：阅读完整的协议规范：标记路由、封装格式、治理控制。
-- [**USDT 作为 Gas 费**](/cn/explanation/usdt-as-gas-token)：了解费用减免方承担的 Gas 费代币。
+- [**启用免 Gas 费交易**](/cn/how-to/integrate-gas-waiver)：通过 API 密钥提交和 NDJSON 响应集成托管的豁免服务器 API。
+- [**Gas 费免除协议**](/cn/reference/gas-waiver-api)：阅读完整的协议规范：标记路由、封装格式、治理控制。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解豁免涵盖的 Gas 令牌。
diff --git a/docs/pages/cn/explanation/key-features.mdx b/docs/pages/cn/explanation/key-features.mdx
index 68f7b05..1b2d825 100755
--- a/docs/pages/cn/explanation/key-features.mdx
+++ b/docs/pages/cn/explanation/key-features.mdx
@@ -1,36 +1,36 @@
---
source_path: explanation/key-features.mdx
-source_sha: 743dbe77cee418846f01652fecf871c2ab504539
+source_sha: 84c73f9671496f1f3dc766dd878111ef4d1b121a
title: '主要功能'
-description: "Stable 的主要技术规格（单槽确定性、USDT0 作为燃料、完全 EVM 兼容性）以及在此基础上构建的 USDT 特有功能。"
+description: "Stable 的亮点规格（单槽最终性、USDT0 作为燃料、完全兼容 EVM）以及在其基础上构建的 USDT 特定功能。"
diataxis: "explanation"
---
# 主要功能
-Stable 是一个委托权益证明 Layer 1，具有单槽最终性、完全 EVM 兼容性，并以 USDT0 作为原生 gas 代币。以下功能决定了日常集成。每个功能都链接到详细介绍它的页面。
+Stable 是一个委托权益证明（Delegated Proof-of-Stake）Layer 1，具有单槽最终性、完全兼容 EVM，并以 USDT0 作为原生燃料代币。以下功能是影响日常集成的关键点。每个功能都链接到详细介绍其内容的页面。
-## 协议级功能
+## 协议级别功能
| 功能 | 含义 |
| :--- | :--- |
-| **单槽确定性** | 交易一旦进入区块即为最终确认。无需多区块确认等待。 |
-| **完全 EVM 兼容性** | Solidity、Vyper、Foundry、Hardhat、ethers、viem 和 `eth_*` RPC 方法无需更改即可工作。 |
-| **USDT0 作为燃料** | 同一资产既是原生余额又是 ERC-20 代币。无需持有单独的 gas 代币。 |
-| **跨链桥接** | USDT0 通过 LayerZero OFT 从 Ethereum、Arbitrum、HyperEVM、Tron 和其他链移动到 Stable。 |
+| **单槽最终性** | 交易一旦进入区块即最终确定。无需等待多区块确认。 |
+| **完全兼容 EVM** | Solidity、Vyper、Foundry、Hardhat、ethers、viem 和 `eth_*` RPC 方法无需修改即可工作。 |
+| **USDT0 作为燃料** | 同一资产既是原生余额又是 ERC-20 代币。无需持有单独的燃料代币。 |
+| **跨链桥接** | USDT0 通过 LayerZero OFT 从以太坊、Arbitrum、HyperEVM、Tron 和其他链转移到 Stable。 |
-## USDT 特有功能
+## USDT 特定功能
-- [**USDT 作为燃料**](/cn/explanation/usdt-as-gas-token)：USDT0 在同一余额中既作为原生 gas 代币又作为 ERC-20 代币。
-- [**Gas 豁免**](/cn/explanation/gas-waiver)：治理授权的豁免提交包装器交易，以零 gas 价格代表用户执行。
-- [**保证区块空间**](/cn/explanation/guaranteed-blockspace)：企业合作伙伴为支付流在每个区块中确保预留容量。
-- [**USDT 转账聚合器**](/cn/explanation/usdt-transfer-aggregator)：大容量 USDT0 转账批量处理成并行化、容错的结算捆绑。
-- [**私密转账**](/cn/explanation/confidential-transfer)：零知识密码学屏蔽转账金额，同时保持参与方可审计。
+- [**USDT0 作为燃料**](/cn/explanation/usdt-as-gas-token)：USDT0 在同一余额中既作为原生燃料代币，又作为 ERC-20 代币。
+- [**燃料豁免**](/cn/explanation/gas-waiver)：经治理授权的豁免会提交包装交易，以零燃料费代表用户执行。
+- [**保证区块空间**](/cn/explanation/guaranteed-blockspace)：企业合作伙伴为支付流在每个区块中获得预留容量。
+- [**USDT 转账聚合器**](/cn/explanation/usdt-transfer-aggregator)：大批量 USDT0 转账被批量处理成并行化、容错的结算捆绑。
+- [**保密转账**](/cn/explanation/confidential-transfer)：零知识密码学保护转账金额，同时保持参与方可审计。
-有关当前已上线和路线图上的升级，请参阅[路线图](/cn/explanation/technical-roadmap)。
+要了解哪些升级已上线，哪些正在开发中，请参阅[路线图](/cn/explanation/technical-roadmap)。
-## 下一步建议
+## 下一步推荐
-- [**以太坊比较**](/cn/explanation/ethereum-comparison)：识别将 DApp 从以太坊移植到 Stable 时保持不变和发生变化的地方。
-- [**资金流向**](/cn/explanation/flow-of-funds)：追踪 USDT 从充值到链上转账再到提现结算。
-- [**架构概览**](/cn/explanation/core-optimization-overview)：了解提供这些功能的共识、执行、数据库和 RPC 层。
+- [**以太坊比较**](/cn/explanation/ethereum-comparison)：了解从以太坊移植到 Stable 时哪些保持不变，哪些发生变化。
+- [**资金流向**](/cn/explanation/flow-of-funds)：追踪 USDT 从入金到链上转账再到出金结算的整个过程。
+- [**架构概览**](/cn/explanation/core-optimization-overview)：深入了解提供这些功能的共识层、执行层、数据库层和 RPC 层。
diff --git a/docs/pages/cn/explanation/learn-overview.mdx b/docs/pages/cn/explanation/learn-overview.mdx
index fc3e380..b9ba4ae 100644
--- a/docs/pages/cn/explanation/learn-overview.mdx
+++ b/docs/pages/cn/explanation/learn-overview.mdx
@@ -1,8 +1,8 @@
---
source_path: explanation/learn-overview.mdx
-source_sha: a3bae707c2afb7477e50291b1b1311296a75a208
+source_sha: f8cb0e6ade6791dce2278fcf48cfe38d1d92c07c
title: "学习"
-description: "Stable 的概念、架构和用例叙述。它是什么，它与以太坊有何不同，以及 USDT0 作为 gas 背后的心智模型。"
+description: "Stable 的概念、架构和用例。它是什么，与以太坊有何不同，以及 USDT0 作为 gas 的心智模型。"
diataxis: "explanation"
---
@@ -10,28 +10,28 @@ diataxis: "explanation"
## 基础
-- [**概览**](/cn/explanation/overview)：Stable 是什么以及如何阅读本文档。
-- [**主要特性**](/cn/explanation/key-features)：主要规格：单槽终结，USDT0 作为 gas，完全 EVM 兼容。
+- [**概述**](/cn/explanation/overview)：Stable 是什么以及如何阅读本文档。
+- [**主要功能**](/cn/explanation/key-features)：亮点：单槽最终确定性，USDT0 作为 gas，完全 EVM 兼容性。
- [**与以太坊的区别**](/cn/explanation/ethereum-comparison)：从以太坊移植时，哪些保持不变，哪些会改变。
-- [**核心概念**](/cn/explanation/core-concepts)：USDT0 双重角色，保证的区块空间，转账聚合器，终结性。
+- [**核心概念**](/cn/explanation/core-concepts)：USDT0 双重角色，保证区块空间，传输聚合器，最终确定性。
## USDT0 行为
-- [**USDT0 在 Stable 上的行为**](/cn/explanation/usdt0-behavior)：双重角色余额、调节事件和合约设计规则。
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：Stable 为什么使用 USDT0 支付 Gas 以及这对费用意味着什么。
-- [**资金流向**](/cn/explanation/flow-of-funds)：USDT 如何在 Stable 上进行端到端转移。
-- [**USDT0 特性**](/cn/explanation/usdt-features-overview)：每个 USDT0 特有的特性，附带链接。
+- [**Stable 上的 USDT0 行为**](/cn/explanation/usdt0-behavior)：双重角色余额，对账事件和合约设计规则。
+- [**USDT0 作为 gas**](/cn/explanation/usdt-as-gas-token)：Stable 为何使用 USDT0 支付 gas 以及这对费用意味着什么。
+- [**资金流**](/cn/explanation/flow-of-funds)：USDT 如何在 Stable 上端到端移动。
+- [**USDT0 功能**](/cn/explanation/usdt-features-overview)：所有 USDT0 特定功能及相关链接。
## 架构
-- [**技术概览**](/cn/explanation/tech-overview)：共识、执行、数据库和 RPC 层都在一页中。
-- [**核心优化**](/cn/explanation/core-optimization-overview)：亚秒级终结性背后的性能工作。
-- [**终结性**](/cn/explanation/finality)：单槽终结性、重组行为以及“已确认”的含义。
-- [**Gas 定价**](/cn/explanation/gas-pricing)：仅基于基础费用的模型，以 USDT0 计价。
+- [**技术概述**](/cn/explanation/tech-overview)：共识、执行、数据库和 RPC 层在一页中。
+- [**核心优化**](/cn/explanation/core-optimization-overview)：实现亚秒级最终确定性背后的性能工作。
+- [**最终确定性**](/cn/explanation/finality)：单槽最终确定性、重组行为以及“已确认”的含义。
+- [**Gas 定价**](/cn/explanation/gas-pricing)：仅以 USDT0 定价的基准费用模型。
-## 用例叙述
+## 用例描述
-- [**支付**](/cn/explanation/use-case-payments)：为什么 Stable 适合 P2P、订阅、发票和按次付费。
-- [**薪资**](/cn/explanation/use-case-payroll)：在 Stable 上进行批量和定期薪资运行。
-- [**赞助交易**](/cn/explanation/use-case-sponsored)：允许应用程序为其用户支付 Gas。
-- [**私密转账**](/cn/explanation/use-case-private)：即将推出的保密支付流程。
+- [**支付**](/cn/explanation/use-case-payments)：Stable 为何适用于 P2P、订阅、发票和按次付费。
+- [**工资**](/cn/explanation/use-case-payroll)：在 Stable 上进行批量和计划的工资发放。
+- [**赞助交易**](/cn/explanation/use-case-sponsored)：允许应用程序为用户支付 gas 费。
+- [**私密转账**](/cn/explanation/use-case-private)：即将推出的机密支付流程。
diff --git a/docs/pages/cn/explanation/technical-roadmap.mdx b/docs/pages/cn/explanation/technical-roadmap.mdx
index 16c2daa..8f8a1db 100755
--- a/docs/pages/cn/explanation/technical-roadmap.mdx
+++ b/docs/pages/cn/explanation/technical-roadmap.mdx
@@ -1,14 +1,14 @@
---
source_path: explanation/technical-roadmap.mdx
-source_sha: e46692a227f4149b54598c9036a27e12659728ee
+source_sha: 12d6268b1d6e265ecdcb13be47d79ee8c3d0e443
title: "路线图"
-description: "Stable 的分阶段优化路线图：今日已上线、即将推出以及未来规划。"
+description: "Stable 阶段性优化路线图：当前已上线功能、即将推出功能以及未来规划。"
diataxis: "explanation"
---
# 路线图
-Stable 从三个阶段优化交易管道的每个层（共识、执行、存储、RPC 和 USDT 特定流程）。本页面标记已发布、正在进行和即将推出的功能。
+Stable 分三阶段优化交易管道的每一层（共识、执行、存储、RPC 和 USDT 特定流程）。本页面将标记已发布、正在进行和仍在规划中的内容。
![]()
= amount, "insufficient balance");
```
-提款必须遵循检查-效果-交互顺序：
+提款必须遵循 Checks-Effects-Interactions 顺序：
```solidity
uint256 amount = credit[msg.sender];
@@ -198,27 +197,27 @@ require(address(this).balance >= amount);
payable(msg.sender).call{value: amount}("");
```
-### 4.3 状态进展必须独立于余额
+### 4.3 状态进展必须与余额无关
-依赖于进展、里程碑或完成条件的协议逻辑必须使用非余额状态变量（例如计数器或纪元）明确跟踪这些变量。
+取决于进展、里程碑或完成条件的协议逻辑必须使用非余额状态变量（例如计数器或纪元）明确跟踪这些条件。
-原生余额只能用于支付时的偿付能力验证。
+原生余额只能用于在支付时验证偿付能力。
### 4.4 授权暴露
-托管用户资金的合约不应向外部地址授予 USDT0 授权。
+保管用户资金的合约不应向外部地址授予 USDT0 授权。
如果授权不可避免，合约应：
- 仅批准确切金额
- 使用后立即重置授权
-- 将剩余的消耗风险视为已知限制
+- 将剩余的耗尽风险视为已知限制
## 5. 地址状态假设
### 5.1 EXTCODEHASH
-合约不得依赖 `EXTCODEHASH(addr) == 0x0` 来推断地址从未被使用过。
+合约不得依赖 `EXTCODEHASH(addr) == 0x0` 来推断某个地址从未被使用。
任何地址使用概念都必须在合约状态中明确跟踪。
@@ -235,68 +234,68 @@ mapping(address => bool) public used;
- 原生 USDT0 转移到 `address(0)` 会回滚。
- ERC20 USDT0 转移到 `address(0)` 也会回滚。
-没有支持的机制通过转移到零地址来销毁 USDT0。
+没有支持的机制可以通过转移到零地址来销毁 USDT0。
合约必须：
-- 明确拒绝 `address(0)` 作为接收者
-- 重新设计任何假设零地址销毁的逻辑
-- 如果需要不可逆的损失语义，请使用明确的接收合约
+- 明确拒绝 `address(0)` 作为接收方
+- 重新设计任何假定零地址销毁的逻辑
+- 如果需要不可逆的损失语义，请使用显式接收器合约
## 7. 测试要求
Stable 部署的测试套件应包括：
-- 基于授权的消耗场景（`approve` + `transferFrom`）
+- 基于授权的耗尽场景（`approve` + `transferFrom`）
- 使用实际原生余额强制执行偿付能力
- 不依赖 `EXTCODEHASH` 的地址使用逻辑
-- 零地址转移的明确失败情况
+- 零地址转移的明确失败案例
-## 8. 迁移核对清单
+## 8. 迁移清单
将合约从以太坊移植到 Stable 时：
- 移除内部原生余额镜像
- 将所有偿付能力检查替换为 `address(this).balance`
-- 移除所有对 `address(0)` 的原生或 ERC20 转移
-- 审计所有 USDT0 审批
-- 添加涵盖许可和基于授权的流程的测试
+- 移除所有到 `address(0)` 的原生或 ERC20 转移
+- 审计所有 USDT0 批准
+- 添加覆盖许可和基于授权的流程的测试
## 9. 总结
-Stable 使用 USDT0 作为 Gas 代币，提供可预测的费用和统一的价值核算，同时改变了对原生余额行为的核心假设。
+Stable 使用 USDT0 作为 gas 代币，提供可预测的费用和统一的价值核算，同时改变了对原生余额行为的核心假设。
-在 Stable 上正确进行合约设计需要：
+在 Stable 上进行正确的合约设计需要：
- 将 USDT0 视为双重角色资产
- 对实际余额强制执行偿付能力
-- 避免基于授权的消耗路径
-- 消除对以太坊特定余额和地址假设的依赖
+- 避免基于授权的耗尽路径
+- 消除对以太坊特定的余额和地址假设的依赖
-## 常见问题
+## 常见问题解答
-**我们今天使用 USDT0 作为封装的原生代币。升级后，哪个代币应该被视为封装的原生代币？**
+### 集成应该将哪个代币视为封装的原生代币？
-升级后，USDT0 既是原生代币又是 ERC-20 代币。您应该直接使用 USDT0，不再需要封装或解封装。
+升级后，USDT0 兼作原生代币和 ERC-20 代币。直接使用 USDT0 即可。您不再需要封装或解封装它。
-**USDT0 原始合约地址 (`0x779Ded0c9e1022225f8E0630b35a9b54bE713736`) 会发生什么？**
+### 原始 USDT0 合约地址会发生什么？
-没有任何变化。相同的地址仍然有效并继续代表 USDT0。
+没有任何变化。`0x779Ded0c9e1022225f8E0630b35a9b54bE713736` 保持有效并继续代表 USDT0。
-**升级后，原生代币地址是 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`（而不是 `0x0000000000000000000000000000000000001000`）吗？**
+### 哪个地址标识原生代币？
-是的。升级后，原生代币标识符/地址是 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`。
+原生代币标识符是 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`，而不是 `0x0000000000000000000000000000000000001000`。
-**那 `0x0000000000000000000000000000000000001000` 呢？它仍然用作 gUSDT 的代币地址吗，我们应该保留它吗？**
+### 集成是否应该保留以前的 gUSDT 地址？
-不。您可以将其删除。升级后将不再使用它。
+否。您可以移除 `0x0000000000000000000000000000000000001000`。升级后不再使用它。
-**对于 DEX calldata，协议会停止使用 `0x0000000000000000000000000000000000001000` 作为“原生代币”标识符，转而使用 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` 吗？**
+### DEX 调用数据应该使用哪个原生代币标识符？
-是的。升级后，DEX 应使用 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` 作为原生代币标识符。
+DEX 调用数据应使用 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` 作为原生代币标识符。
-## 下一步推荐
+## 推荐阅读
-- [**发送您的第一个 USDT0**](/cn/tutorial/send-usdt0)：使用标准的 EVM 工具在测试网上提交 USDT0 传输。
-- [**Gas 定价**](/cn/reference/gas-pricing-api)：根据 Stable 的单一组件费用模型构建交易。
-- [**USDT0 在 Stable 上的行为**](/cn/explanation/usdt0-behavior)：审计合约，检查双重角色资产语义、余额核对和 `EXTCODEHASH` 行为。
+- [**发送您的第一个 USDT0**](/cn/tutorial/send-usdt0)：使用标准 EVM 工具在测试网上提交 USDT0 转账。
+- [**Gas 定价**](/cn/reference/gas-pricing-api)：根据 Stable 的单组件费用模型构建交易。
+- [**Stable 上的 USDT0 行为**](/cn/explanation/usdt0-behavior)：审计合约，检查双重角色资产语义、余额核对和 `EXTCODEHASH` 行为。
diff --git a/docs/pages/cn/explanation/usdt-features-overview.mdx b/docs/pages/cn/explanation/usdt-features-overview.mdx
index 45f1efb..d8c03e3 100755
--- a/docs/pages/cn/explanation/usdt-features-overview.mdx
+++ b/docs/pages/cn/explanation/usdt-features-overview.mdx
@@ -1,43 +1,43 @@
---
source_path: explanation/usdt-features-overview.mdx
-source_sha: 57d3ff5eccb576fb54ee22d218ee257c2e845bff
-title: "概览"
-description: "Stable 的五个 USDT 特定功能如何协同工作，使稳定币支付流能够大规模实际应用。"
+source_sha: c60f456a8e4e135e4a648496f7628719b8f18d23
+title: "概述"
+description: "Stable 的五项 USDT 特定功能如何协同工作，使稳定币支付流程能够实际规模化应用。"
diataxis: "explanation"
---
-# 概览
+# 概述
-Stable 的 USDT 特有功能并非独立的选项菜单。它们相互复合。每个功能都消除了稳定币支付从演示走向生产过程中出现的特定摩擦。本页面解释了这五个功能为何协同存在。
+Stable 的 USDT 特定功能并非相互独立的选项菜单。它们相互补充。每一个都消除了稳定币支付从演示走向生产时出现的特定摩擦。本页面解释了这五项功能为何会协同存在。
## 摩擦堆栈
-通用链上大多数稳定币支付架构都会遇到相同的系列问题：
+通用链上大多数稳定币支付架构都会遇到相同的堆栈问题：
-1. **用户必须持有第二种代币**（ETH、SOL）才能支付用于移动稳定币的交易费用。这是一个导致转化率流失的入门步骤。
-2. **即使有第二种代币，用户也必须支付 Gas 费。**这打破了商家和支付应用所需的“一美元对一美元”的心理模型。
-3. **交易成本随网络活动波动。**薪资、财务操作和批量结算无法规划成本或纳入考量。
-4. **每笔交易的限制降低了吞吐量。**高容量的 USDT 流会遇到全链竞争，并与不相关的活动一起退化。
-5. **每笔交易都是公开可见的。**供应商付款、薪资发放和财务操作会泄露商业敏感数据。
+1. **用户必须持有第二种代币**（ETH、SOL）来支付移动稳定币的交易燃气费。这是一种会导致转换率流失的入职步骤。
+2. **即使有第二种代币，用户也必须支付燃气费。** 这打破了商家和支付应用所需要的“一美元发一美元”心智模型。
+3. **交易成本随网络活动而波动。** 工资、财务操作和批量结算无法规划成本或纳入。
+4. **每笔交易限制了吞吐量。** 大批量 USDT 流动会遇到全链竞争，并与不相关的活动一起退化。
+5. **每笔交易都可公开观察。** 供应商付款、工资发放和财务流转会泄露商业敏感数据。
-## 功能如何协同
+## 功能如何组合
-Stable 通过专用机制解决了每个摩擦：
+Stable 通过专用机制解决每项摩擦：
| 摩擦 | 机制 | 页面 |
| :--- | :--- | :--- |
-| 单独的 Gas 代币 | USDT0 是原生 Gas 代币 | [USDT 作为 Gas](/cn/explanation/usdt-as-gas-token) |
-| 用户支付所有 Gas | 治理授权的豁免涵盖 Gas | [Gas 豁免](/cn/explanation/gas-waiver) |
-| 成本和纳入差异 | 为注册合作伙伴保留区块容量 | [保证区块空间](/cn/explanation/guaranteed-blockspace) |
-| 吞吐量上限 | 并行化 USDT0 传输批处理 | [USDT 传输聚合器](/cn/explanation/usdt-transfer-aggregator) |
-| 公开数量可见性 | 通过 ZK 加密实现选择性隐私 | [保密传输](/cn/explanation/confidential-transfer) |
+| 单独的燃气代币 | USDT0 是原生燃气代币 | [USDT0 作为燃气代币](/cn/explanation/usdt-as-gas-token) |
+| 用户支付所有燃气费 | 治理授权豁免涵盖燃气费 | [燃气费豁免](/cn/explanation/gas-waiver) |
+| 成本和纳入差异 | 为注册合作伙伴预留区块容量 | [保证区块空间](/cn/explanation/guaranteed-blockspace) |
+| 吞吐量上限 | 并行化 USDT0 转账批处理 | [USDT 转账聚合器](/cn/explanation/usdt-transfer-aggregator) |
+| 公开金额可见性 | 通过 ZK 密码学实现选择性隐私 | [保密转账](/cn/explanation/confidential-transfer) |
-其中任何一个都有帮助。综合起来，它们使 Stable 成为一个链，支付团队可以在其中像在传统卡网络上一样，对成本、延迟和隐私进行建模，并具有区块链的结算最终性。
+其中任何一项都有帮助。将它们结合起来，Stable 就成为一条链，支付团队可以在这条链上像在传统卡网络上一样建模成本、延迟和隐私，同时拥有区块链的结算终局性。
-有关 Stable 与通用 EVM 链之间的所有区别，请参阅[以太坊比较](/cn/explanation/ethereum-comparison)。有关 USDT 经过这些功能端到端移动的具体示例，请参阅[资金流](/cn/explanation/flow-of-funds)。
+有关 Stable 与通用 EVM 链之间所有差异的完整说明，请参阅[以太坊对比](/cn/explanation/ethereum-comparison)。有关 USDT 如何通过这些功能进行端到端移动的示例，请参阅[资金流](/cn/explanation/flow-of-funds)。
-## 推荐下一步
+## 下一步建议
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解同时替代 ETH 作为 Gas 和支付的资产。
-- [**资金流**](/cn/explanation/flow-of-funds)：追踪 USDT 从充值到链上转账再到提现结算的全过程。
-- [**将 USDT0 桥接到 Stable**](/cn/explanation/usdt0-bridging)：了解 USDT0 如何从其他链移动到 Stable。
+- [**USDT0 作为燃气代币**](/cn/explanation/usdt-as-gas-token)：了解可同时替代 ETH 用于燃气和支付的资产。
+- [**资金流**](/cn/explanation/flow-of-funds)：跟踪 USDT 从入金到链上转账再到出金结算的整个过程。
+- [**将 USDT0 桥接到 Stable**](/cn/explanation/usdt0-bridging)：了解 USDT0 如何从其他链移动到 Stable。
diff --git a/docs/pages/cn/explanation/usdt-transfer-aggregator.mdx b/docs/pages/cn/explanation/usdt-transfer-aggregator.mdx
index 131943c..c04896c 100755
--- a/docs/pages/cn/explanation/usdt-transfer-aggregator.mdx
+++ b/docs/pages/cn/explanation/usdt-transfer-aggregator.mdx
@@ -1,14 +1,14 @@
---
source_path: explanation/usdt-transfer-aggregator.mdx
-source_sha: 23229418f878c0594cd6e8e891e188b95df6c4ec
+source_sha: 65a8d11eab81088117f6db9c762a3c9bc95cdea4
title: "USDT 转账聚合器"
-description: "USDT 转账聚合器将大批量 USDT0 转账批量处理成并行、容错的结算。"
+description: "USDT 转账聚合器将大批量 USDT0 转账批处理为并行、容错的结算。"
diataxis: "explanation"
---
# USDT 转账聚合器
-**USDT 转账聚合器**将 USDT0 转账打包成并行、容错的批次，而不是按顺序处理每笔转账。它将 USDT0 的吞吐量与执行管道的其余部分隔离开来，因此大批量的稳定币活动不会挤占其他交易。
+**USDT 转账聚合器**将 USDT0 转账打包成并行、容错的批次，而不是顺序处理每笔转账。它将 USDT0 吞吐量与执行管道的其余部分隔离开来，因此大批量稳定币活动不会挤占其他交易。
:::note
**计划中。** 聚合器是一个具有前瞻性的路线图项目。以下内容描述了目标设计。有关时间安排，请参阅[路线图](/cn/explanation/technical-roadmap)。
@@ -16,69 +16,69 @@ diataxis: "explanation"
## 存在原因
-两个约束相互拉扯：
+两个制约因素相互矛盾：
-- 传统的 ERC-20 转账是按顺序处理的。在高负载下，这是一个瓶颈。
+- 传统的 ERC-20 转账是顺序处理的。在高负载下，这是一个瓶颈。
- 简单地给 USDT0 优先级会挤占其他交易并降低一般链性能。
-聚合器通过将 USDT0 转账拉入专门的并行管道来解决这个问题，使主执行路径保持不变，以处理其他所有事务。
+聚合器通过将 USDT0 转账拉入专用的并行管道来解决这个问题，将主执行路径留给其他所有内容。
-## 并行聚合与验证
+## 并行聚合和验证
-转账聚合系统的核心是可并行化的聚合与验证管道，其灵感来自 `MapReduce` 计算模型。系统不是按顺序处理每笔转账，而是执行捆绑级别的计算，在执行余额更新之前聚合跨账户的输入和输出。
+转账聚合系统的核心是一个可并行化的聚合和验证管道，其灵感来自 `MapReduce` 计算模型。系统不是按顺序处理每笔转账，而是执行捆绑级别计算，在执行余额更新之前聚合账户的输入和输出。
### 关键步骤
-1. **聚合账户差异**
- - 每笔转账都映射到发送方和接收方。
- - 为每个账户生成一个代表净代币移动的差异日志：
- - 借记总额（发送）为负值。
- - 贷记总额（接收）为正值。
-2. **余额验证**
- - 系统确保全局余额不变量：总输入等于总输出。
- - 每个账户的净变化都独立并行验证，以确认资金充足。
- - 资金不足的账户会被标记，而不会暂停捆绑。
-3. **用于并行的 MapReduce 模型**
- - **Map 阶段**：根据所有传入/传出转账计算每个账户的净增量。
- - **Reduce 阶段**：聚合这些增量以确定最终状态更新。
+1. **聚合账户差异**
+ - 每笔转账都映射到发送方和接收方。
+ - 为每个账户生成一个差异日志，表示净代币移动：
+ - 总借方（发送）为负值。
+ - 总贷方（接收）为正值。
+2. **余额验证**
+ - 系统确保全局余额不变性：总输入等于总输出。
+ - 每个账户的净变化都独立并行验证，以确认资金充足。
+ - 余额不足的账户将被标记，而不会停止捆绑。
+3. **MapReduce 模型实现并行化**
+ - **Map 阶段**：根据所有传入/传出转账计算每个账户的净差额。
+ - **Reduce 阶段**：聚合这些差额以确定最终状态更新。
## 技术亮点
### 并行计算模型
-- 利用预编译合约中的并行性来并发检查余额和计算差异。
-- 与传统的顺序 ERC20 处理相比，大大减少了执行时间。
+- 利用预编译合约中的并行性来并发检查余额和计算差异。
+- 与传统的顺序 ERC20 处理相比，大大减少了执行时间。
### 依赖分析
-- 识别重叠转账（例如，来自同一账户的多次发送）。
-- 预先标记高风险转账（例如，可能资金不足），以最大限度地减少级联故障。
+- 识别重叠转账（例如，来自同一账户的多次发送）。
+- 预先标记高风险转账（例如，可能资金不足）以最大程度地减少级联故障。
### 模块化故障处理
-- 转账在账户级别进行隔离，因此只有有问题的账户受到影响。
-- 非冲突转账正常执行并最终确定。
+- 转账在账户级别隔离，因此只有有问题的账户会受到影响。
+- 不冲突的转账正常执行并最终确定。
### 选择性故障处理
-传统的转账处理在一个区块内是全有或全无的。Stable 的聚合模型引入了细粒度的、按账户的故障隔离：
+传统的转账处理在一个区块内是全有或全无的。Stable 的聚合模型引入了粒度化的、按账户的故障隔离：
-- 如果账户的 `当前余额 + 净差异 < 0`，系统仅将该账户的转账标记为失败。
-- 涉及其他账户的转账照常进行。
-- 这种选择性回滚机制确保无效或恶意转账不会损害整个捆绑的完整性。
+- 如果账户的 `当前余额 + 净差额 < 0`，系统仅将该账户的转账标记为失败。
+- 涉及其他账户的转账正常进行。
+- 这种选择性回滚机制确保无效或恶意转账不会损害整个捆绑的完整性。
## 提议者驱动或基于声誉的排序
为了进一步优化执行并避免状态冲突，Stable 结合了聚合转账的预处理排序机制：
-- **基于声誉的排序**：具有良好历史或经验证可靠性的发送方被优先处理，从而降低失败和重新排序的风险。
-- **基于提议者的排序**：交易可以由受信任的提议者节点排序，该节点构建捆绑以最大程度地减少冲突并最大化吞吐量。
-- **捆绑转账优先**：聚合的 USDT 转账优先于一般交易，从而减少依赖冲突并开启更清晰的执行窗口。
+- **基于声誉的排序**：具有良好历史记录或经验证可靠性的发送者优先，从而降低失败和重新排序的风险。
+- **基于提议者的排序**：交易可以由受信任的提议者节点排序，该节点构造捆绑以最大程度地减少冲突并最大化吞吐量。
+- **捆绑转账优先级**：聚合的 USDT 转账在一般交易之前优先，从而减少依赖冲突并开启更清晰的执行窗口。
-Stable 的 USDT 转账聚合器是一种有针对性的优化，可在不降低一般交易处理速度的情况下最大限度地提高 USDT0 转账的吞吐量。通过结合并行执行、模块化故障处理和智能排序策略，Stable 为稳定币驱动的经济提供了可扩展的基础。快速、频繁和无摩擦的代币转账成为常态。
+Stable 的 USDT 转账聚合器是一项有针对性的优化，可最大化 USDT0 转账的吞吐量，而不会降低一般交易处理。通过结合并行执行、模块化故障处理和智能排序策略，Stable 为稳定币驱动的经济提供了可扩展的基础。快速、频繁和无摩擦的代币转账是常态。
## 下一步建议
-- [**支付用例**](/cn/explanation/payment-use-cases-overview)：查看从聚合吞吐量中受益最大的支付模式：P2P、订阅、按次付费。
-- [**执行**](/cn/explanation/execution)：查看聚合器构建于其上的并行执行引擎。
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解聚合器所移动的资产模型。
+- [**支付用例**](/cn/explanation/payment-use-cases-overview)：查看从聚合吞吐量中受益最大的支付模式：P2P、订阅、按次付费。
+- [**执行**](/cn/explanation/execution)：查看聚合器所基于的并行执行引擎。
+- [**USDT0 作为手续费**](/cn/explanation/usdt-as-gas-token)：了解聚合器所移动的资产模型。
diff --git a/docs/pages/cn/explanation/usdt0-behavior.mdx b/docs/pages/cn/explanation/usdt0-behavior.mdx
index 662acee..c3bb1ae 100644
--- a/docs/pages/cn/explanation/usdt0-behavior.mdx
+++ b/docs/pages/cn/explanation/usdt0-behavior.mdx
@@ -1,37 +1,37 @@
---
source_path: explanation/usdt0-behavior.mdx
-source_sha: 17a1c5d1a4aae70266159154d52063d08fbb0378
-title: "USDT0 在 Stable 上的行为"
-description: "USDT0 在 Stable 上既是原生资产又是 ERC-20 代币。审计合约以进行余额核对、代币许可安全和操作码行为检查。"
+source_sha: 88ba67e3146da4f4e00e35291ef2e2270c9fa68c
+title: "Stable 上的 USDT0 行为"
+description: "USDT0 在 Stable 上既是原生资产也是 ERC-20 代币。审计合约以进行余额核对、代币授权安全性和操作码行为检查。"
diataxis: "explanation"
---
-# USDT0 在 Stable 上的行为
+# Stable 上的 USDT0 行为
-**如果你正在从以太坊移植合约，在部署前请阅读此页面。** Stable 上的 USDT0 既是原生 Gas 代币，又是同一个余额上的 ERC-20 代币。因此，四种以太坊假定的行为会受到影响：合约的原生余额会未调用合约而发生变化，`EXTCODEHASH` 可以在零和空哈希之间振荡，零地址转账会回滚，以及一个逻辑转账可能会由于小数余额核对而发出多个 `Transfer` 事件。
+**如果您要从以太坊移植合约，请在部署前阅读此页面。** Stable 上的 USDT0 既是原生 Gas 代币，也是同一余额上的 ERC-20 代币。因此，四种以太坊假定的行为会失效：合约的原生余额可以在没有调用合约的情况下发生变化、`EXTCODEHASH` 可以在零和空哈希之间振荡、零地址转账会回滚，以及一次逻辑转账可能会由于小数余额核对而发出多个 `Transfer` 事件。
-本页面将详细介绍每种情况，并提供安全的合约模式。如果你只阅读一个部分，请阅读[迁移清单](#migration-checklist)。这是将你的以太坊合约移植到这里的摘要。
+本页面将介绍每种情况并提供安全的合约模式。如果您只阅读一个部分，请阅读[迁移清单](#migration-checklist)。这是将您的以太坊合约移植到此处的总结。
## 双重角色概述
-Stable 上的 USDT0 既是原生 Gas 代币，又是 ERC-20 代币。这种双重角色模型会影响余额行为、合约设计和事件处理。以下各节将详细介绍双重角色改变预期行为的每种情况。
+Stable 上的 USDT0 既是原生 Gas 代币，也是 ERC-20 代币。这种双重角色模型影响余额行为、合约设计和事件处理。以下各节将介绍双重角色改变预期行为的所有情况。
-有关 USDT0 为什么以这种方式运行的背景信息，请参阅[USDT 作为 Gas](/cn/explanation/usdt-as-gas-token)。要通过真实转账体验这种行为，请参阅[发送你的第一个 USDT0](/cn/tutorial/send-usdt0)。
+有关 USDT0 为什么以这种方式运作的背景信息，请参阅 [USDT0 作为 Gas](/cn/explanation/usdt-as-gas-token)。要通过实际转账体验该行为，请参阅[发送您的第一个 USDT0](/cn/tutorial/send-usdt0)。
## 余额核对
-USDT0 作为原生资产使用 18 位小数，作为 ERC-20 代币使用 6 位小数。原生转账和 ERC-20 转账在同一个底层余额上操作，但 12 位的精度差距意味着当转账涉及小于整数的精度时，系统必须核对小数金额。
+USDT0 作为原生资产使用 18 位小数，作为 ERC-20 代币使用 6 位小数。原生转账和 ERC-20 转账在相同的底层余额上操作，但 12 位精度的差距意味着当转账涉及亚整数精度时，系统必须核对小数金额。
```text
before
- 0.000001 USDT0 (ERC-20) + 0.000000000000000000 USDT0 (内部)
+ 0.000001 USDT0 (ERC-20) + 0.000000000000000000 USDT0 (internal)
// address(account).balance = 0.000001000000000000
// USDT0.balanceOf(account) = 0.000001
-如果将 0.0000001 USDT0 转账到另一个账户
+if transfer 0.0000001 USDT0 to another account
after
- 0.000000 USDT0 (ERC-20) + 0.000000900000000000 USDT0 (内部)
+ 0.000000 USDT0 (ERC-20) + 0.000000900000000000 USDT0 (internal)
// address(account).balance = 0.000000900000000000
// USDT0.balanceOf(account) = 0.000000
```
@@ -40,30 +40,30 @@ after
## 事件处理
-每次核对转账都会发出一个额外的 `Transfer` 事件。一次逻辑上的 USDT0 转账最多可以产生两个额外的 `Transfer` 事件，具体取决于发送方和接收方小数余额受到的影响：
+每次核对转账都会额外发出一个 `Transfer` 事件。一次逻辑 USDT0 转账可能会产生最多两个额外的 `Transfer` 事件，具体取决于发送方和接收方的小数余额如何受到影响：
-- **发送方调整**：如果发送方的小数余额不足，0.000001 USDT0 会从发送方转移到保留地址。这会发出一个额外的 `Transfer` 事件。
-- **接收方调整**：如果接收方的小数余额溢出，0.000001 USDT0 会从保留地址转移到接收方。这会发出一个额外的 `Transfer` 事件。
-- **双向调整**：如果两个条件在同一笔转账中发生，则会绕过保留地址。发送方会将 0.000001 USDT0 作为主转账的一部分直接转账给接收方。不会发出额外的事件。
+- **发送方调整**：如果发送方的小数余额不足，0.000001 USDT0 会从发送方转移到储备地址。这会发出一个额外的 `Transfer` 事件。
+- **接收方调整**：如果接收方的小数余额溢出，0.000001 USDT0 会从储备地址转移到接收方。这会发出一个额外的 `Transfer` 事件。
+- **两者兼有**：如果同一转账中同时出现两种情况，则会绕过储备。发送方将 0.000001 USDT0 作为主要转账的一部分直接转移给接收方。不会发出额外的事件。
-这些辅助事件涉及保留地址 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`。通过重放 `Transfer` 事件来跟踪 USDT0 余额的索引器和链下服务必须过滤或考虑进出此地址的转账。
+这些辅助事件涉及储备地址 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`。通过重放 `Transfer` 事件跟踪 USDT0 余额的索引器和链下服务必须过滤或考虑进出此地址的转账。
## 合约设计要求
### 原生余额可变性
-在以太坊上，合约的原生余额通常只因合约执行而改变。在 Stable 上，合约的原生 USDT0 余额也可能因基于 ERC-20 许可的操作而改变，包括 `transferFrom` 和 `permit`。这些操作可以在不调用任何合约代码的情况下减少合约的原生余额。
+在以太坊上，合约的原生余额通常仅因合约执行而改变。在 Stable 上，合约的原生 USDT0 余额也可能因基于 ERC-20 授权的操作而改变，包括 `transferFrom` 和 `permit`。这些操作可以在不调用任何合约代码的情况下减少合约的原生余额。
-因此，以下假设在 Stable 上是无效的：
+因此，以下假设在 Stable 上无效：
-> 合约的原生余额只有在合约被调用时才会减少。
+> 合约的原生余额只有在调用合约时才会减少。
### 不要镜像原生余额
-在以太坊上，使用内部变量跟踪存款是很常见的。在 Stable 上，这是不安全的，因为 ERC-20 `transferFrom` 可以在外部耗尽原生余额。
+在以太坊上，使用内部变量跟踪存款很常见。在 Stable 上，这是不安全的，因为 ERC-20 `transferFrom` 可能会从外部耗尽原生余额。
```solidity
-// 在 Stable 上不安全
+// UNSAFE on Stable
uint256 public deposited;
function deposit() external payable {
@@ -71,55 +71,55 @@ function deposit() external payable {
}
```
-### 在转账前始终检查真实余额
+### 在转账前务必检查真实余额
-所有原生价值转账都必须在转账前使用 `address(this).balance` 验证偿付能力，而不是内部会计变量：
+所有原生价值转账都必须在转账前使用 `address(this).balance` 验证偿付能力，而不是内部记账变量：
```solidity
-// 安全
+// SAFE
function withdraw() external {
uint256 amount = credit[msg.sender];
credit[msg.sender] = 0;
- require(address(this).balance >= amount, "余额不足");
+ require(address(this).balance >= amount, "insufficient balance");
payable(msg.sender).call{value: amount}("");
}
```
-### 状态进展必须与余额无关
+### 状态进展必须独立于余额
-依赖于进展、里程碑或完成条件的协议逻辑必须使用非余额状态变量（例如计数器或纪元）明确跟踪这些条件。原生余额应仅用于支付时的偿付能力验证。
+依赖进展、里程碑或完成条件的协议逻辑必须使用非余额状态变量（例如计数器或时期）明确跟踪这些。原生余额应仅用于支付时验证偿付能力。
### 无零地址转账
-在 Stable 上，无论是原生转账还是 ERC-20 转账到 `address(0)` 都会回滚。
+在 Stable 上，原生和 ERC-20 转账到 `address(0)` 都会回滚。
```solidity
-// 在 Stable 上回滚
+// REVERT on Stable
payable(address(0)).call{value: amount}("")
USDT0.transfer(address(0), amount);
```
-任何发送原生 USDT0 的合约逻辑都应在转账调用前验证接收方并明确拒绝 `address(0)`：
+任何发送原生 USDT0 的合约逻辑都应在转账调用之前验证接收方并明确拒绝 `address(0)`：
```solidity
-// 安全
-require(recipient != address(0), "零地址接收方");
+// SAFE
+require(recipient != address(0), "zero address recipient");
payable(recipient).call{value: amount}("");
```
-如果合约使用零地址转账作为销毁机制，则必须重新设计。如果需要不可逆转的损失语义，请使用显式接收器合约。
+如果合约使用零地址转账作为销毁机制，则必须重新设计。如果需要不可逆的损失语义，请使用显式汇集合约。
### EXTCODEHASH 行为
在以太坊上，`EXTCODEHASH` 操作码返回：
-- **零哈希** (`0x0000...`)：如果一个地址从未使用过（nonce=0，balance=0，无代码）。
-- **空哈希** (`0xc5d2…a470`，空代码的 Keccak-256 哈希）：如果一个地址存在但没有代码。
+- **零哈希** (`0x0000...`)：如果地址从未被使用（nonce=0，balance=0，无代码）。
+- **空哈希** (`0xc5d2…a470`，空代码的 Keccak-256 哈希）：如果地址存在但没有代码。
-在以太坊上，一旦一个地址从零哈希变为为空哈希，它就不能再返回到零哈希。在 Stable 上，因为 USDT0 支持基于 `permit()` 的许可，一个地址可以创建许可而无需发送交易。结合 `transferFrom()`，这允许在不增加 nonce 的情况下更改原生余额，这可能导致 `EXTCODEHASH` 在零哈希和空哈希之间振荡。
+在以太坊上，一旦地址从零哈希变为为空哈希，就不能再返回零哈希。在 Stable 上，由于 USDT0 支持基于 `permit()` 的批准，地址可以在不发送交易的情况下创建批准。结合 `transferFrom()`，这允许在不增加 nonce 的情况下更改原生余额，这可能导致 `EXTCODEHASH` 在零哈希和空哈希之间振荡。
```solidity
-// 在 Stable 上不安全
+// UNSAFE on Stable
function isUnusedAddress(address addr) public view returns (bool) {
bytes32 codeHash;
assembly {
@@ -132,7 +132,7 @@ function isUnusedAddress(address addr) public view returns (bool) {
请改用显式跟踪：
```solidity
-// 安全
+// SAFE
contract SafeAddressTracker {
mapping(address => bool) public hasBeenUsed;
@@ -150,38 +150,38 @@ contract SafeAddressTracker {
Stable 部署的测试套件应包括：
-- 基于许可的耗尽场景（`approve` + `transferFrom`）
+- 基于授权的耗尽场景（`approve` + `transferFrom`）
- 使用真实原生余额强制执行偿付能力
- 不依赖 `EXTCODEHASH` 的地址使用逻辑
-- 零地址转账的明确失败情况
+- 零地址转账的明确失败案例
## 迁移清单
将合约从以太坊移植到 Stable 时：
-- 移除内部原生余额镜像
+- 删除内部原生余额镜像
- 将所有偿付能力检查替换为 `address(this).balance`
-- 移除所有到 `address(0)` 的原生或 ERC-20 转账
-- 审计所有 USDT0 许可
-- 添加涵盖 `permit` 和基于许可流程的测试
+- 删除所有到 `address(0)` 的原生或 ERC-20 转账
+- 审计所有 USDT0 批准
+- 添加覆盖 `permit` 和基于授权的流程的测试
- 验证链下索引器是否处理小数余额核对产生的辅助 `Transfer` 事件
-## 关键要点
+## 主要收获
-在 Stable 上进行正确的合约设计需要：
+Stable 上正确的合约设计需要：
- 将 USDT0 视为双重角色资产
- 根据真实余额强制执行偿付能力
-- 避免基于许可的耗尽路径
-- 消除对以太坊特定余额和地址假设的依赖
+- 避免基于授权的耗尽路径
+- 消除对以太坊特定的余额和地址假设的依赖
链下服务和索引器应：
-- 考虑小数余额核对产生的辅助 `Transfer` 事件
+- 考虑来自小数余额核对的辅助 `Transfer` 事件
- 使用直接余额查询而不是基于事件的余额重建
-## 推荐阅读
+## 下一步建议
-- [**USDT 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解 USDT0 为什么既作为原生资产又作为 ERC-20 代币运行。
-- [**发送你的第一个 USDT0**](/cn/tutorial/send-usdt0)：在测试网上通过原生和 ERC-20 路径提交 USDT0 转账。
-- [**以太坊对比**](/cn/explanation/ethereum-comparison)：查看从以太坊移植时的所有行为差异。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token)：了解为什么 USDT0 既是原生资产又是 ERC-20 代币。
+- [**发送您的第一个 USDT0**](/cn/tutorial/send-usdt0)：通过原生和 ERC-20 路径在测试网上提交 USDT0 转账。
+- [**以太坊对比**](/cn/explanation/ethereum-comparison)：回顾从以太坊移植时所有的行为差异。
diff --git a/docs/pages/cn/explanation/usdt0-bridging.mdx b/docs/pages/cn/explanation/usdt0-bridging.mdx
index a497580..a6e011f 100644
--- a/docs/pages/cn/explanation/usdt0-bridging.mdx
+++ b/docs/pages/cn/explanation/usdt0-bridging.mdx
@@ -1,6 +1,6 @@
---
source_path: explanation/usdt0-bridging.mdx
-source_sha: e7c69b0ee925f0a348e16c6ca7a11c490739c061
+source_sha: e8ffad6d8ed33c1c3ffca3fece2da78a79369b10
title: "将 USDT0 桥接到 Stable"
description: "了解 USDT0 和原生 USDT 如何通过 OFT Mesh 和 Legacy Mesh 到达 Stable。"
diataxis: "explanation"
@@ -12,8 +12,8 @@ USDT 通过两种桥接路径之一到达 Stable，具体取决于它在源链
:::note
**两条路径，一个结果：**
-- **OFT Mesh**：源链已经有 USDT0。在源链上销毁，在 Stable 上铸造。跨链 1:1。示例：Arbitrum, Ethereum, Optimism, Polygon, Unichain, Ink, Bera, Mantle, Hyperliquid, MegaETH (共 21 条链)。
-- **Legacy Mesh**：源链只有原生 USDT。通过 Arbitrum 作为中心路由。收取传输金额的 0.03% 费用。示例：Tron, TON。
+- **OFT Mesh**：源链已经有 USDT0。在源链上销毁，在 Stable 上铸造。跨链 1:1。示例：Arbitrum、Ethereum、Optimism、Polygon、Unichain、Ink、Bera、Mantle、Hyperliquid、MegaETH（共 21 条链）。
+- **Legacy Mesh**：源链只有原生 USDT。通过 Arbitrum 作为中心路由。收取转移金额的 0.03% 费用。示例：Tron、TON。
:::
以下部分详细描述了每条路径。
@@ -24,23 +24,23 @@ Stable 参与了两个互补的跨链传输网络。
### OFT Mesh
-任何支持 USDT0 的链都可以参与 OFT Mesh。在 OFT Mesh 中，USDT0 跨链传输保持 1:1 的价值比率。当发生传输时，源链上的 USDT0 代币被销毁，并在目标链上铸造等量的代币。当前的 OFT Mesh 参与者包括 Arbitrum, Bera, Conflux, Ethereum, Flare, Hedera, Hyperliquid, Ink, Mantle, MegaETH, Monad, Morph, MP1, Optimism, Plasma, Polygon, Rootstock, Sei, Stable, Tempo, Unichain, 和 X Layer。
+任何支持 USDT0 的链都可以参与 OFT Mesh。在 OFT Mesh 中，USDT0 跨链传输保持 1:1 的价值比率。当发生传输时，源链上的 USDT0 代币被销毁，并在目的链上铸造等量的代币。当前的 OFT Mesh 参与者包括 Arbitrum、Bera、Conflux、Ethereum、Flare、Hedera、Hyperliquid、Ink、Mantle、MegaETH、Monad、Morph、MP1、Optimism、Plasma、Polygon、Rootstock、Sei、Stable、Tempo、Unichain 和 X Layer。
### Legacy Mesh
-任何拥有原生 USDT（而非 USDT0）的链都可以通过 Legacy Mesh 路由。Legacy Mesh 采用星形结构，Arbitrum 作为 USDT0 的中心枢纽。该模型利用 Arbitrum 上的 USDT0 流动性池。USDT0 团队对传输金额收取 0.03% 的费用。当前的 Legacy Mesh 参与者包括 Tron 和 TON。
+任何具有原生 USDT（而非 USDT0）的链都可以通过 Legacy Mesh 进行路由。Legacy Mesh 遵循中心辐射型架构，Arbitrum 作为 USDT0 的中心枢纽。该模型利用 Arbitrum 上的 USDT0 流动性池。USDT0 团队对转移金额收取 0.03% 的费用。当前的 Legacy Mesh 参与者包括 Tron 和 TON。
-Ethereum 和 Arbitrum 参与了两个 Mesh：这些链上的用户可以通过 OFT 路径（销毁/铸造 USDT0）或 Legacy 路径（通过 Arbitrum 中心锁定原生 USDT）进行桥接。
+Ethereum 和 Arbitrum 同时参与了这两种 Mesh：这些链上的用户可以通过 OFT 路径（销毁/铸造 USDT0）或 Legacy 路径（通过 Arbitrum 枢纽锁定原生 USDT）进行桥接。
---
-## 路径 1：将 USDT0 桥接到 Stable（OFT 支持的链）
+## 路径 1: 将 USDT0 桥接到 Stable (OFT 支持的链)
-当用户已经在 OFT 支持的源链（如 Arbitrum 或 Ink）上持有 USDT0 时，适用此路径。
+此路径适用于用户已在 OFT 支持的源链（如 Arbitrum 或 Ink）上持有 USDT0 的情况。
### 参与者
-| 名称 | 链上？ | 责任方 |
+| 名称 | 链上？ | 负责方 |
| --- | --- | --- |
| 用户 | N/A | 用户 |
| USDT0 OUpgradable | ✅ | USDT0 的智能合约 |
@@ -57,47 +57,47 @@ Ethereum 和 Arbitrum 参与了两个 Mesh：这些链上的用户可以通过 O
### 详细步骤
-#### 1. 发起传输（链上，源链）
+#### 1. 发起传输 (链上，源链)
用户在源链上调用 **USDT0 OUpgradable** 合约的 `lzSend` 方法。交易包括消息负载、目标 LayerZero 端点和合约地址，以及诸如 gas 限制和费用之类的配置参数。
-#### 2. 数据包创建（链上，源链）
+#### 2. 数据包创建 (链上，源链)
-源 LayerZero Endpoint 封装 OApp 的消息，使用指定的源 MessageLib 合约对其进行编码，并将其发送到安全堆栈 (DVN) 和 Executor，完成发送交易。
+源链 LayerZero Endpoint 封装 OApp 的消息，使用指定源 MessageLib 合约对其进行编码，并将其发送到 Security Stack (DVN) 和 Executor，完成发送交易。
-#### 3. 消息验证（链下，DVN）
+#### 3. 消息验证 (链下，DVN)
-去中心化验证器网络（DVN）在目标合约执行消息之前独立验证消息。只有 OApp 授权的 DVN 才能执行验证。USDT0 桥接要求三个 DVN 签署每条消息：LayerZero Labs, Canary, 和 USDT0。有关任何路径上的规范配置，请参见 [LayerZeroScan 上的 USDT0 OApp](https://layerzeroscan.com/)。
+去中心化验证网络 (DVN) 在目标合约执行消息之前独立验证消息。只有 OApp 授权的 DVN 才能执行验证。USDT0 桥接需要三个 DVN 签署每条消息：LayerZero Labs、Canary 和 USDT0。有关任何路径的规范配置，请参阅 [USDT0 在 LayerZeroScan 上的 OApp](https://layerzeroscan.com/)。
-#### 4. 标记为可验证（链上，Stable）
+#### 4. 标记为可验证 (链上，Stable)
-一旦所有必需的 DVN 验证了消息，目标 MessageLib 合约将其标记为可验证。
+一旦所有必需的 DVN 验证了消息，目标 MessageLib 合约就会将其标记为可验证。
-#### 5. 验证提交（链下，Executor）
+#### 5. 验证承诺 (链下，Executor)
Executor 将已验证的消息提交给目标 LayerZero Endpoint，为执行做准备。
-#### 6. 数据包验证（链上，Stable）
+#### 6. 数据包验证 (链上，Stable)
-目标 LayerZero Endpoint 确认 Executor 传递的数据包与 DVN 验证的数据包匹配。
+目标 LayerZero Endpoint 确认 Executor 交付的数据包与 DVN 验证的数据包匹配。
-#### 7. 消息执行（链下，Executor）
+#### 7. 消息执行 (链下，Executor)
Executor 在目标链上调用 `lzReceive`，触发 Stable 上的 USDT0 OUpgradable 合约处理消息。
-#### 8. 完成（链上，Stable）
+#### 8. 完成 (链上，Stable)
Stable 上的 USDT0 OUpgradable 合约处理已验证的消息，完成跨链传输。USDT0 被铸造到用户的地址。
---
-## 路径 2：将原生 USDT 桥接到 Stable（Legacy Mesh）
+## 路径 2: 将原生 USDT 桥接到 Stable (Legacy Mesh)
-当用户在 Legacy Mesh 链（如 Tron）上持有原生 USDT 时，适用此路径。传输通过 Arbitrum 作为中间枢纽，然后到达 Stable。
+此路径适用于用户在 Legacy Mesh 链（如 Tron）上持有原生 USDT 的情况。传输通过 Arbitrum 作为中间枢纽，然后到达 Stable。
### 参与者
-| 名称 | 链上？ | 责任方 |
+| 名称 | 链上？ | 负责方 |
| --- | --- | --- |
| 用户 | N/A | 用户 |
| USDT Pool | ✅ | USDT0 的智能合约 |
@@ -118,34 +118,34 @@ Stable 上的 USDT0 OUpgradable 合约处理已验证的消息，完成跨链传
### 详细步骤
-#### 1. 发起传输（链上，Tron）
+#### 1. 发起传输 (链上，Tron)
-用户发起桥接交易，并将原生 USDT 发送到 Tron 上的 **USDT Pool** 合约。USDT 被锁定在池中。USDT Pool 合约随后向 Tron 上的 LayerZero Endpoint 合约发送一条消息。
+用户发起桥接交易，并将原生 USDT 发送到 Tron 上的 **USDT Pool** 合约。USDT 被锁定在池中。USDT Pool 合约随后向 Tron 上的 LayerZero Endpoint 合约发送消息。
-#### 2. 发送消息到 Legacy Mesh（链下）
+#### 2. 向 Legacy Mesh 发送消息 (链下)
LayerZero Endpoint 合约将消息发送到 **USDT0 Legacy Mesh Operator**，后者验证消息。
-#### 3. 发起 MultiHop 传输（链上，Arbitrum）
+#### 3. 发起 MultiHop 传输 (链上，Arbitrum)
-USDT0 Legacy Mesh Operator 调用 Arbitrum 上的 LayerZero **MultiHopComposer** 合约的 `lzCompose()` 方法。无需额外的用户交互，MultiHopComposer 合约执行从 Arbitrum 到 Stable 的 USDT0 铸造-销毁桥接传输。
+USDT0 Legacy Mesh Operator 在 Arbitrum 上调用 LayerZero **MultiHopComposer** 合约的 `lzCompose()` 方法。无需额外的用户交互，MultiHopComposer 合约执行从 Arbitrum 到 Stable 的 USDT0 铸造和销毁桥接传输。
:::note
-MultiHopComposer 合约是完全无需许可的，并且没有 `owner()` 以确保不可变性。
+MultiHopComposer 合约完全无权限，没有 `owner()` 以确保不可变性。
:::
-#### 4. 将 USDT0 传输到 Stable（链上和链下）
+#### 4. 将 USDT0 传输到 Stable (链上和链下)
-剩余步骤与[将 USDT0 桥接到 Stable](#path-1--bridging-usdt0-to-stable-oft-supported-chains) 的路径完全相同（上述步骤 1-8）。Arbitrum 上的 USDT0 OUpgradable 合约通过 LayerZero 发送，DVN 进行验证，然后在 Stable 上铸造 USDT0。
+剩余步骤遵循与[将 USDT0 桥接到 Stable](#path-1--bridging-usdt0-to-stable-oft-supported-chains) 完全相同的路径（以上步骤 1-8）。Arbitrum 上的 USDT0 OUpgradable 合约通过 LayerZero 发送，DVN 进行验证，并在 Stable 上铸造 USDT0。
### 注意事项
- Arbitrum 上的 USDT0 流动性由 USDT0 团队管理。
- Legacy Mesh 对传输金额收取 0.03% 的费用。
-- 用户不需要直接与 Arbitrum 交互；MultiHop 流程是自动的。
+- 用户无需直接与 Arbitrum 交互；MultiHop 流程是自动的。
-## 推荐阅读
+## 下一步建议
-- [**资金流向**](/cn/explanation/flow-of-funds)：了解 USDT 从入金到结算的端到端生命周期。
-- [**桥接教程**](/cn/tutorial/bridge-usdt0)：使用 LayerZero OFT Adapter 将测试 USDT 从 Sepolia 桥接到 Stable 测试网。
-- [**USDT 作为 gas**](/cn/explanation/usdt-as-gas-token)：了解资产到达 Stable 后会做什么。
+- [**资金流**](/cn/explanation/flow-of-funds)：查看 USDT 从上线到结算的端到端生命周期。
+- [**桥接教程**](/cn/tutorial/bridge-usdt0)：使用 LayerZero OFT 适配器将 Test USDT 从 Sepolia 桥接到 Stable 测试网。
+- [**USDT0 作为 gas**](/cn/explanation/usdt-as-gas-token)：了解资产到达 Stable 后会做什么。
diff --git a/docs/pages/cn/explanation/use-case-payments.mdx b/docs/pages/cn/explanation/use-case-payments.mdx
index 1177031..77e0b57 100644
--- a/docs/pages/cn/explanation/use-case-payments.mdx
+++ b/docs/pages/cn/explanation/use-case-payments.mdx
@@ -1,27 +1,27 @@
---
source_path: explanation/use-case-payments.mdx
-source_sha: a5e26e7574265dccbb0f71370598384bdeeea5f6
+source_sha: 9685590c6fb8bb68a3a4b8be6c907bf5547d0372
title: "支付与转账"
-description: "Stable 如何通过单资产模型、零费用用户体验和即时终结性支持 P2P 支付和商家结算。"
+description: "Stable 如何通过单资产模型、零费用用户体验和即时最终性来支持点对点支付和商家结算。"
diataxis: "explanation"
---
# 支付与转账
-P2P 支付和商家结算围绕一种资产构建，这种资产既用于资金转移也用于支付交易费用。
+点对点支付和商家结算围绕单一资产构建，该资产用于资金流动和支付交易。
## 问题
-在通用链上，用户必须持有单独的 Gas 代币（ETH、SOL）才能转移稳定币。这打破了“发送一美元，接收一美元”的心智模型，并在用户入驻时造成了转换流失，因为一个只有 USDT 的支付者甚至无法提交转账。
+在通用链上，用户必须持有单独的 Gas 代币（ETH、SOL）才能转移稳定币。这打破了“发送一美元，接收一美元”的心智模型，导致新用户注册时出现转换流失，因为只有 USDT 的付款人甚至无法提交转账。
## Stable 如何解决
-- **USDT0 既是 Gas 代币也是支付资产。** 用户只需一种资产即可发送或接收。请参阅[作为 Gas 的 USDT](/cn/explanation/usdt-as-gas-token)。
+- **USDT0 既是 Gas 代币也是支付资产。** 用户只需一种资产即可发送或接收。请参阅[USDT0 作为 Gas](/cn/explanation/usdt-as-gas-token)。
- **Gas 豁免允许应用程序代表用户支付 Gas**，从而实现零费用用户体验，而用户无需接触第二种代币。请参阅[Gas 豁免](/cn/explanation/gas-waiver)。
-- **单槽最终性意味着结算即时。** 一旦转账进入区块，它就是最终的。请参阅[以太坊对比](/cn/explanation/ethereum-comparison)。
+- **单槽最终性意味着即时结算。** 一旦转账进入区块，它就是最终的。请参阅[以太坊对比](/cn/explanation/ethereum-comparison)。
## 下一步建议
-- [**作为 Gas 的 USDT**](/cn/explanation/usdt-as-gas-token)：了解同时替代 ETH 作为 Gas 和支付的资产。
-- [**Gas 豁免**](/cn/explanation/gas-waiver)：了解应用程序如何通过治理批准的豁免地址支付用户 Gas。
-- [**以太坊对比**](/cn/explanation/ethereum-comparison)：回顾从以太坊迁移时发生的变化（最终性、Gas 代币、优先提示）。
+- [**USDT0 作为 Gas**](/cn/explanation/usdt-as-gas-token): 了解替代 ETH 用于 Gas 和支付的资产。
+- [**Gas 豁免**](/cn/explanation/gas-waiver): 了解应用程序如何通过治理批准的豁免地址支付用户 Gas。
+- [**以太坊对比**](/cn/explanation/ethereum-comparison): 审查从以太坊迁移时发生的变化（最终性、Gas 代币、优先小费）。
diff --git a/docs/pages/en/explanation/bank-module.mdx b/docs/pages/en/explanation/bank-module.mdx
index c19264a..d1e8701 100755
--- a/docs/pages/en/explanation/bank-module.mdx
+++ b/docs/pages/en/explanation/bank-module.mdx
@@ -39,4 +39,4 @@ The full method signatures, event payloads, and authorization flow are in the [B
- [**Bank precompile reference**](/en/reference/bank-module-api): Call `transfer`, `approve`, `mint`, `burn`, and read events.
- [**System modules overview**](/en/explanation/system-modules-overview): Return to the full list of precompile-exposed modules.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the dual-role asset model the bank module manages.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the dual-role asset model the bank module manages.
diff --git a/docs/pages/en/explanation/confidential-transfer.mdx b/docs/pages/en/explanation/confidential-transfer.mdx
index 44b9b00..d4f49b5 100755
--- a/docs/pages/en/explanation/confidential-transfer.mdx
+++ b/docs/pages/en/explanation/confidential-transfer.mdx
@@ -53,6 +53,6 @@ Confidential Transfer is in development. See [Roadmap](/en/explanation/technical
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model confidential transfers shield.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model confidential transfers shield.
- [**Flow of funds**](/en/explanation/flow-of-funds): See where confidentiality fits in the end-to-end payment lifecycle.
- [**Roadmap**](/en/explanation/technical-roadmap): Track when confidential transfer ships.
diff --git a/docs/pages/en/explanation/eip-7702.mdx b/docs/pages/en/explanation/eip-7702.mdx
index 599d3ed..4d8d9ee 100755
--- a/docs/pages/en/explanation/eip-7702.mdx
+++ b/docs/pages/en/explanation/eip-7702.mdx
@@ -47,5 +47,5 @@ After submission, the EOA's account code is set to the delegate. Subsequent tran
## Next recommended
- [**Account Abstraction (EIP-7702)**](/en/reference/eip-7702-api): Implement batch payments, spending limits, and session keys against a delegate contract.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the gas model that EIP-7702 transactions run on.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the gas model that EIP-7702 transactions run on.
- [**Gas waiver**](/en/explanation/gas-waiver): Compare delegation to gas-waived flows where an application pays the user's gas instead.
diff --git a/docs/pages/en/explanation/erc-3009.mdx b/docs/pages/en/explanation/erc-3009.mdx
index 355aa51..b8359b8 100755
--- a/docs/pages/en/explanation/erc-3009.mdx
+++ b/docs/pages/en/explanation/erc-3009.mdx
@@ -91,6 +91,6 @@ This property is what makes ERC-3009 on Stable a strong foundation for higher-le
**See also:**
-- [USDT as Gas](/en/explanation/usdt-as-gas-token)
+- [USDT0 as gas](/en/explanation/usdt-as-gas-token)
- [USDT0 Behavior on Stable](/en/explanation/usdt0-behavior)
- [x402 (HTTP-Native Payments)](/en/explanation/x402)
diff --git a/docs/pages/en/explanation/ethereum-comparison.mdx b/docs/pages/en/explanation/ethereum-comparison.mdx
index 899ef03..a54f979 100755
--- a/docs/pages/en/explanation/ethereum-comparison.mdx
+++ b/docs/pages/en/explanation/ethereum-comparison.mdx
@@ -46,7 +46,7 @@ On Stable, transaction fees are paid in USDT0, not a volatile native token. This
- Users need USDT0 in their wallet to submit transactions.
- The `value` field in transactions still works for sending USDT0, similar to how ETH is sent on Ethereum.
-- See [USDT as gas](/en/explanation/usdt-as-gas-token) for details.
+- See [USDT0 as gas](/en/explanation/usdt-as-gas-token) for details.
### 3. No priority tips
@@ -74,6 +74,6 @@ USDT0 functions as both the native gas token and an ERC-20 token. This introduce
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model that replaces ETH for gas.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model that replaces ETH for gas.
- [**Gas pricing**](/en/explanation/gas-pricing): Review the single-component fee model in detail.
- [**USDT0 behavior on Stable**](/en/explanation/usdt0-behavior): Audit contracts for dual-role asset semantics, allowance safety, and `EXTCODEHASH` behavior.
diff --git a/docs/pages/en/explanation/flow-of-funds.mdx b/docs/pages/en/explanation/flow-of-funds.mdx
index cfc1ee6..a5cf76c 100755
--- a/docs/pages/en/explanation/flow-of-funds.mdx
+++ b/docs/pages/en/explanation/flow-of-funds.mdx
@@ -60,6 +60,6 @@ The conversion logic (e.g., BTC → USDT) may be handled by an exchange partner,
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand how USDT0 serves as both native gas and ERC-20 balance on Stable.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand how USDT0 serves as both native gas and ERC-20 balance on Stable.
- [**Bridging USDT0 to Stable**](/en/explanation/usdt0-bridging): See how USDT0 moves onto Stable from other chains via OFT Mesh or Legacy Mesh.
- [**Send your first USDT0**](/en/tutorial/send-usdt0): Submit a USDT0 transfer on testnet using standard EVM tooling.
diff --git a/docs/pages/en/explanation/gas-pricing.mdx b/docs/pages/en/explanation/gas-pricing.mdx
index cee9553..2f2ac15 100755
--- a/docs/pages/en/explanation/gas-pricing.mdx
+++ b/docs/pages/en/explanation/gas-pricing.mdx
@@ -36,5 +36,5 @@ Stable accepts EIP-1559 (Type 2) transactions, but `maxPriorityFeePerGas` is alw
## Next recommended
- [**Gas pricing reference**](/en/reference/gas-pricing-api): Construct transactions, estimate gas, and configure tooling against Stable's fee model.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): See how USDT0 serves as both native gas and ERC-20 balance.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): See how USDT0 serves as both native gas and ERC-20 balance.
- [**Ethereum comparison**](/en/explanation/ethereum-comparison): Review every behavior difference you'll encounter porting from Ethereum.
diff --git a/docs/pages/en/explanation/gas-waiver.mdx b/docs/pages/en/explanation/gas-waiver.mdx
index 7995b37..a03f510 100755
--- a/docs/pages/en/explanation/gas-waiver.mdx
+++ b/docs/pages/en/explanation/gas-waiver.mdx
@@ -56,4 +56,4 @@ For flows where the user does hold USDT0 but wants to bundle multiple calls into
- [**Enable gas-free transactions**](/en/how-to/integrate-gas-waiver): Integrate the hosted Waiver Server API with API-key submission and NDJSON responses.
- [**Gas waiver protocol**](/en/reference/gas-waiver-api): Read the full protocol spec: marker routing, wrapper format, governance controls.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the gas token that the waiver covers.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the gas token that the waiver covers.
diff --git a/docs/pages/en/explanation/key-features.mdx b/docs/pages/en/explanation/key-features.mdx
index 743dbe7..84c73f9 100755
--- a/docs/pages/en/explanation/key-features.mdx
+++ b/docs/pages/en/explanation/key-features.mdx
@@ -19,7 +19,7 @@ Stable is a delegated Proof-of-Stake Layer 1 with single-slot finality, full EVM
## USDT-specific features
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): USDT0 serves as both the native gas token and an ERC-20 token on the same balance.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): USDT0 serves as both the native gas token and an ERC-20 token on the same balance.
- [**Gas waiver**](/en/explanation/gas-waiver): Governance-authorized waivers submit wrapper transactions that execute at zero gas price on the user's behalf.
- [**Guaranteed blockspace**](/en/explanation/guaranteed-blockspace): Enterprise partners secure reserved capacity in every block for payment flows.
- [**USDT transfer aggregator**](/en/explanation/usdt-transfer-aggregator): High-volume USDT0 transfers batch into parallelized, fault-tolerant settlement bundles.
diff --git a/docs/pages/en/explanation/learn-overview.mdx b/docs/pages/en/explanation/learn-overview.mdx
index a3bae70..f8cb0e6 100755
--- a/docs/pages/en/explanation/learn-overview.mdx
+++ b/docs/pages/en/explanation/learn-overview.mdx
@@ -16,7 +16,7 @@ diataxis: "explanation"
## USDT0 behavior
- [**USDT0 behavior on Stable**](/en/explanation/usdt0-behavior): Dual-role balance, reconciliation events, and contract design rules.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Why Stable uses USDT0 to pay for gas and what that means for fees.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Why Stable uses USDT0 to pay for gas and what that means for fees.
- [**Flow of funds**](/en/explanation/flow-of-funds): How USDT moves end-to-end across Stable.
- [**USDT0 features**](/en/explanation/usdt-features-overview): Every USDT0-specific feature with links to each.
diff --git a/docs/pages/en/explanation/technical-roadmap.mdx b/docs/pages/en/explanation/technical-roadmap.mdx
index e46692a..12d6268 100755
--- a/docs/pages/en/explanation/technical-roadmap.mdx
+++ b/docs/pages/en/explanation/technical-roadmap.mdx
@@ -22,9 +22,9 @@ Status: **Live on mainnet.**
A customized PoS consensus protocol built on CometBFT. Delivers deterministic finality and Byzantine fault tolerance up to one-third of validators. See [Consensus](/en/explanation/consensus) for the current implementation.
-### USDT as native gas: Live
+### USDT0 as native gas: Live
-USDT0 is the native asset for gas payment and value transfer, and simultaneously supports the ERC-20 surface (`approve`, `transfer`, `transferFrom`, `permit`). See [USDT as gas](/en/explanation/usdt-as-gas-token).
+USDT0 is the native asset for gas payment and value transfer, and simultaneously supports the ERC-20 surface (`approve`, `transfer`, `transferFrom`, `permit`). See [USDT0 as gas](/en/explanation/usdt-as-gas-token).
### Stable Pay & Stable Name: In progress
diff --git a/docs/pages/en/explanation/usdt-as-gas-token.mdx b/docs/pages/en/explanation/usdt-as-gas-token.mdx
index 8097bf3..48402b6 100755
--- a/docs/pages/en/explanation/usdt-as-gas-token.mdx
+++ b/docs/pages/en/explanation/usdt-as-gas-token.mdx
@@ -1,10 +1,10 @@
---
-title: USDT as gas
+title: USDT0 as gas
description: "How USDT0 functions as Stable's native gas token, replacing volatile assets for predictable transaction fees."
diataxis: "explanation"
---
-# USDT as gas
+# USDT0 as gas
**You pay fees in USDT0. No second token, no wrapping, no ETH-equivalent to keep topped up.** USDT0 serves as both the native gas token and an ERC-20 token on the same balance. The same asset that moves as payment also pays for the transaction that moves it. Fees are denominated in dollars, not a volatile native token.
@@ -272,25 +272,25 @@ Correct contract design on Stable requires:
## FAQ
-**We’re using USDT0 as the wrapped native token today. After this upgrade, which token should be treated as the wrapped native?**
+### Which token should integrations treat as the wrapped native token?
-USDT0 becomes both the native token and an ERC-20 token after the upgrade. You should use USDT0 directly, and wrapping or unwrapping is no longer required.
+USDT0 becomes both the native token and an ERC-20 token after the upgrade. Use USDT0 directly. You no longer need to wrap or unwrap it.
-**What happens to the original USDT0 contract address (`0x779Ded0c9e1022225f8E0630b35a9b54bE713736`)?**
+### What happens to the original USDT0 contract address?
-Nothing changes. The same address remains valid and continues to represent USDT0.
+Nothing changes. `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` remains valid and continues to represent USDT0.
-**After the upgrade, is the native token address `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` (instead of `0x0000000000000000000000000000000000001000`)?**
+### Which address identifies the native token?
-Yes. After the upgrade, the native token identifier/address is `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`.
+The native token identifier is `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`, not `0x0000000000000000000000000000000000001000`.
-**What about `0x0000000000000000000000000000000000001000`? Is it still used as the token address for gUSDT, and should we keep it on our side?**
+### Should integrations keep the former gUSDT address?
-No. You can remove it. It will not be used after the upgrade.
+No. You can remove `0x0000000000000000000000000000000000001000`. It isn't used after the upgrade.
-**For DEX calldata, will protocols stop using `0x0000000000000000000000000000000000001000` as the “native token” identifier and use `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` instead?**
+### Which native token identifier should DEX calldata use?
-Correct. After the upgrade, DEXs should use `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` as the native token identifier.
+DEX calldata should use `0x779Ded0c9e1022225f8E0630b35a9b54bE713736` as the native token identifier.
## Next recommended
diff --git a/docs/pages/en/explanation/usdt-features-overview.mdx b/docs/pages/en/explanation/usdt-features-overview.mdx
index 57d3ff5..c60f456 100755
--- a/docs/pages/en/explanation/usdt-features-overview.mdx
+++ b/docs/pages/en/explanation/usdt-features-overview.mdx
@@ -24,7 +24,7 @@ Stable addresses each friction with a dedicated mechanism:
| Friction | Mechanism | Page |
| :--- | :--- | :--- |
-| Separate gas token | USDT0 is the native gas token | [USDT as gas](/en/explanation/usdt-as-gas-token) |
+| Separate gas token | USDT0 is the native gas token | [USDT0 as gas](/en/explanation/usdt-as-gas-token) |
| User pays gas at all | Governance-authorized waivers cover gas | [Gas waiver](/en/explanation/gas-waiver) |
| Cost and inclusion variance | Reserved block capacity for enrolled partners | [Guaranteed blockspace](/en/explanation/guaranteed-blockspace) |
| Throughput ceiling | Parallelized USDT0 transfer batching | [USDT transfer aggregator](/en/explanation/usdt-transfer-aggregator) |
@@ -36,6 +36,6 @@ For the full set of Stable's differences from a general-purpose EVM chain, see [
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset that replaces ETH for gas and payment at once.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the asset that replaces ETH for gas and payment at once.
- [**Flow of funds**](/en/explanation/flow-of-funds): Trace USDT from on-ramp through on-chain transfer to off-ramp settlement.
- [**Bridging USDT0 to Stable**](/en/explanation/usdt0-bridging): See how USDT0 moves onto Stable from other chains.
diff --git a/docs/pages/en/explanation/usdt-transfer-aggregator.mdx b/docs/pages/en/explanation/usdt-transfer-aggregator.mdx
index 2322941..65a8d11 100755
--- a/docs/pages/en/explanation/usdt-transfer-aggregator.mdx
+++ b/docs/pages/en/explanation/usdt-transfer-aggregator.mdx
@@ -79,4 +79,4 @@ Stable's USDT Transfer Aggregator is a targeted optimization that maximizes thro
- [**Payments use cases**](/en/explanation/payment-use-cases-overview): See the payment patterns that benefit most from aggregated throughput: P2P, subscriptions, pay-per-call.
- [**Execution**](/en/explanation/execution): See the parallel execution engine the aggregator builds on.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model the aggregator moves.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the asset model the aggregator moves.
diff --git a/docs/pages/en/explanation/usdt0-behavior.mdx b/docs/pages/en/explanation/usdt0-behavior.mdx
index 17a1c5d..88ba67e 100755
--- a/docs/pages/en/explanation/usdt0-behavior.mdx
+++ b/docs/pages/en/explanation/usdt0-behavior.mdx
@@ -14,7 +14,7 @@ This page walks through each case and gives safe contract patterns. If you only
USDT0 on Stable is both the native gas token and an ERC-20 token. This dual-role model affects balance behavior, contract design, and event handling. The sections below walk through every case where the dual role changes expected behavior.
-For background on why USDT0 operates this way, see [USDT as gas](/en/explanation/usdt-as-gas-token). To experience the behavior through real transfers, see [Send your first USDT0](/en/tutorial/send-usdt0).
+For background on why USDT0 operates this way, see [USDT0 as gas](/en/explanation/usdt-as-gas-token). To experience the behavior through real transfers, see [Send your first USDT0](/en/tutorial/send-usdt0).
## Balance reconciliation
@@ -180,6 +180,6 @@ Off-chain services and indexers should:
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand why USDT0 operates as both the native asset and an ERC-20 token.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand why USDT0 operates as both the native asset and an ERC-20 token.
- [**Send your first USDT0**](/en/tutorial/send-usdt0): Submit a USDT0 transfer on testnet via native and ERC-20 paths.
- [**Ethereum comparison**](/en/explanation/ethereum-comparison): Review every behavior difference when porting from Ethereum.
diff --git a/docs/pages/en/explanation/usdt0-bridging.mdx b/docs/pages/en/explanation/usdt0-bridging.mdx
index e7c69b0..e8ffad6 100755
--- a/docs/pages/en/explanation/usdt0-bridging.mdx
+++ b/docs/pages/en/explanation/usdt0-bridging.mdx
@@ -146,4 +146,4 @@ The remaining steps follow the exact same path as [bridging USDT0 to Stable](#pa
- [**Flow of funds**](/en/explanation/flow-of-funds): See the end-to-end lifecycle of USDT from on-ramp through settlement.
- [**Bridge tutorial**](/en/tutorial/bridge-usdt0): Bridge Test USDT from Sepolia to Stable testnet using the LayerZero OFT Adapter.
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand what the asset does once it lands on Stable.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand what the asset does once it lands on Stable.
diff --git a/docs/pages/en/explanation/use-case-payments.mdx b/docs/pages/en/explanation/use-case-payments.mdx
index a5e26e7..9685590 100755
--- a/docs/pages/en/explanation/use-case-payments.mdx
+++ b/docs/pages/en/explanation/use-case-payments.mdx
@@ -14,12 +14,12 @@ On general-purpose chains, users must hold a separate gas token (ETH, SOL) just
## How Stable addresses it
-- **USDT0 is both the gas token and the payment asset.** A user only ever needs one asset to send or receive. See [USDT as gas](/en/explanation/usdt-as-gas-token).
+- **USDT0 is both the gas token and the payment asset.** A user only ever needs one asset to send or receive. See [USDT0 as gas](/en/explanation/usdt-as-gas-token).
- **Gas waiver lets applications cover gas on behalf of users**, enabling a zero-fee UX without the user touching a second token. See [Gas waiver](/en/explanation/gas-waiver).
- **Single-slot finality means settlement is immediate.** Once a transfer is in a block, it's final. See [Ethereum comparison](/en/explanation/ethereum-comparison).
## Next recommended
-- [**USDT as gas**](/en/explanation/usdt-as-gas-token): Understand the asset that replaces ETH for gas and payment at once.
+- [**USDT0 as gas**](/en/explanation/usdt-as-gas-token): Understand the asset that replaces ETH for gas and payment at once.
- [**Gas waiver**](/en/explanation/gas-waiver): See how applications cover user gas through governance-approved waiver addresses.
- [**Ethereum comparison**](/en/explanation/ethereum-comparison): Review what changes (finality, gas token, priority tips) when moving from Ethereum.
diff --git a/docs/pages/ko/explanation/bank-module.mdx b/docs/pages/ko/explanation/bank-module.mdx
index 8e60f98..8c46bc0 100755
--- a/docs/pages/ko/explanation/bank-module.mdx
+++ b/docs/pages/ko/explanation/bank-module.mdx
@@ -1,44 +1,44 @@
---
source_path: explanation/bank-module.mdx
-source_sha: c19264aa3a4aa590a16f97192b30d5ffe1d88b08
+source_sha: d1e8701c692bce3df6e4d7c6e16cf350e18165ef
title: "뱅크 모듈"
-description: "뱅크 사전 컴파일은 SDK x/bank 모듈을 기반으로 하는 ERC-20 호환 토큰 전송과 발행, 소각, 승인 메서드를 노출합니다."
+description: "뱅크 사전 컴파일은 SDK x/bank 모듈을 기반으로 하는 ERC-20 호환 토큰 전송과 민트, 번, 승인 메서드를 노출합니다."
diataxis: "explanation"
---
# 뱅크 모듈
-Stable의 SDK에 있는 `x/bank` 모듈은 토큰 잔액, 전송, 공급을 처리합니다. EVM 표면( **뱅크 사전 컴파일**)은 이 모듈을 래핑하고 ERC-20 시맨틱과 특권 발행/소각 작업에 대한 승인 계층을 추가합니다. Stable에서 토큰을 이동해야 하는 컨트랙트는 자체 토큰 구현을 배포하지 않고 사전 컴파일을 직접 호출합니다.
+Stable의 SDK에 있는 `x/bank` 모듈은 토큰 잔액, 전송 및 공급을 처리합니다. EVM 표면(**뱅크 사전 컴파일**)은 이 모듈을 래핑하고 ERC-20 시맨틱과 권한 있는 민트/번 작업에 대한 승인 계층을 추가합니다. Stable에서 토큰을 이동해야 하는 계약은 자체 토큰 구현을 배포하지 않고 사전 컴파일을 직접 호출합니다.
-## 노출되는 기능
+## 노출되는 내용
-뱅크 사전 컴파일은 표준 ERC-20 메서드를 제공합니다.
+뱅크 사전 컴파일은 표준 ERC-20 메서드를 제공합니다:
- `transfer`, `balanceOf`, `totalSupply`
- `approve`, `transferFrom`, `allowance`, `revoke`
-이들은 어떤 호출자에게든 작동합니다. 등록이 필요하지 않습니다.
+이 메서드는 모든 호출자에서 작동합니다. 등록이 필요하지 않습니다.
-또한 특권 메서드를 제공합니다.
+또한 다음 privileged 메서드를 제공합니다:
- `mint`: 새 토큰을 발행하고 계정으로 전송합니다.
- `burn`: 계정이 보유한 토큰을 소각합니다.
-- `multiTransfer`: 한 번의 호출로 토큰을 한 발신자에서 여러 수신자에게 이동합니다.
+- `multiTransfer`: 단일 호출로 한 발신자에서 여러 수신자에게 토큰을 이동합니다.
-발행 및 소각은 호출자 컨트랙트가 거버넌스 제안을 통해 `x/precompile` 허용 목록에 등록되어야 합니다. 거버넌스 토큰 발행은 전면적으로 차단됩니다. 이는 공급 증가를 승인된 컨트랙트에만 국한시킵니다.
+민트 및 번은 호출자 계약이 거버넌스 제안을 통해 `x/precompile` 허용 목록에 등록되어야 합니다. 거버넌스 토큰 발행은 완전히 차단됩니다. 이는 공급 인플레이션을 승인된 계약으로만 제한합니다.
-## 사용 시점
+## 언제 사용해야 하는가
-- DeFi 컨트랙트가 사용자 대신 STABLE 또는 USDT0을 이동해야 하는 경우: 사전 컴파일에서 `transfer` 또는 `transferFrom`을 직접 호출합니다.
-- 프로토콜 컨트랙트가 비즈니스 로직에 따라 토큰을 발행하거나 소각하는 경우: 먼저 거버넌스를 통해 등록한 다음 `mint`/`burn`을 호출합니다.
-- 결제 컨트랙트가 일대다 지불이 필요한 경우: 루프 전송 대신 단일 트랜잭션으로 `multiTransfer`를 호출합니다.
+- DeFi 계약이 사용자 대신 STABLE 또는 USDT0를 이동해야 하는 경우: 사전 컴파일에서 `transfer` 또는 `transferFrom`을 직접 호출합니다.
+- 프로토콜 계약이 비즈니스 로직에 따라 토큰을 발행하거나 소각하는 경우: 먼저 거버넌스를 통해 등록한 다음 `mint`/`burn`을 호출합니다.
+- 지불 계약이 다수에 대한 지불이 필요한 경우: 루프 전송 대신 단일 트랜잭션에서 `multiTransfer`를 호출합니다.
-## ABI를 찾는 방법
+## ABI를 찾을 수 있는 곳
-전체 메서드 서명, 이벤트 페이로드 및 승인 흐름은 [뱅크 사전 컴파일 참조](/ko/reference/bank-module-api)에서 확인할 수 있습니다.
+전체 메서드 시그니처, 이벤트 페이로드 및 승인 흐름은 [뱅크 사전 컴파일 참조](/ko/reference/bank-module-api)에서 확인할 수 있습니다.
## 다음 권장 사항
-- [**뱅크 사전 컴파일 참조**](/ko/reference/bank-module-api): `transfer`, `approve`, `mint`, `burn`을 호출하고 이벤트를 읽습니다.
-- [**시스템 모듈 개요**](/ko/explanation/system-modules-overview): 사전 컴파일이 노출하는 모듈의 전체 목록으로 돌아갑니다.
-- [**가스 토큰으로서의 USDT**](/ko/explanation/usdt-as-gas-token): 뱅크 모듈이 관리하는 이중 역할 자산 모델을 이해합니다.
+- [**뱅크 사전 컴파일 참조**](/ko/reference/bank-module-api): `transfer`, `approve`, `mint`, `burn`을 호출하고 이벤트를 읽으세요.
+- [**시스템 모듈 개요**](/ko/explanation/system-modules-overview): 사전 컴파일이 노출하는 전체 모듈 목록으로 돌아갑니다.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): 뱅크 모듈이 관리하는 이중 역할 자산 모델을 이해합니다.
diff --git a/docs/pages/ko/explanation/confidential-transfer.mdx b/docs/pages/ko/explanation/confidential-transfer.mdx
index 21a2cb9..ebe5a27 100755
--- a/docs/pages/ko/explanation/confidential-transfer.mdx
+++ b/docs/pages/ko/explanation/confidential-transfer.mdx
@@ -1,60 +1,60 @@
---
source_path: explanation/confidential-transfer.mdx
-source_sha: 44b9b0047f5252a2aa10b8e93a64f42854c9182d
+source_sha: d4f49b5013bdf924bef68a0c154c4d23e524fa3d
title: "기밀 전송"
-description: "Stable에서 규제 준수를 통한 프라이버시 보호 USDT 트랜잭션을 위한 기밀 전송 메커니즘."
+description: "Stable에서 규제 준수를 통해 개인 정보 보호 USDT 트랜잭션을 위한 기밀 전송 메커니즘."
diataxis: "explanation"
---
# 기밀 전송
-**기밀 전송(Confidential Transfer)**은 발신자 및 수신자 주소를 공개적으로 볼 수 있도록 유지하면서 USDT0 전송의 **금액**을 보호하는 Stable의 프라이버시 계층입니다. 보호된 금액은 트랜잭션 당사자와 승인된 규제 감사관만 읽을 수 있으며, 영지식(ZK) 암호화를 사용하여 값을 공개하지 않고 유효성을 증명합니다. 이 기능은 개발 중이며, 이 페이지에서는 대상 모델에 대해 설명합니다.
+**기밀 전송**은 Stable의 개인정보 보호 계층으로, USDT0 전송의 **금액**을 보호하는 동시에 송신자와 수신자 주소는 공개적으로 표시됩니다. 보호되는 금액은 트랜잭션 당사자와 승인된 규제 감사자만이 읽을 수 있으며, 영지식(ZK) 암호화를 사용하여 값을 공개하지 않고 유효성을 증명합니다. 이 기능은 현재 개발 중이며, 이 페이지에서는 대상 모델에 대해 설명합니다.
## 해결하는 문제
-표준 온체인 전송은 완벽하게 투명합니다. 누구든지 발신자, 수신자 및 금액을 읽을 수 있습니다. 비즈니스 결제의 경우 이러한 투명성은 데이터 유출 문제입니다.
+표준 온체인 전송은 완전히 투명하며, 누구든지 송신자, 수신자 및 금액을 읽을 수 있습니다. 비즈니스 결제의 경우 이러한 투명성은 데이터 유출 문제입니다.
-- 온체인에서 공급업체에 비용을 지불하는 소매업체는 모든 관찰자에게 주문량 및 도매 가격을 노출합니다.
-- 계정 간에 자금을 이동하는 재무부는 포지션 규모를 광고합니다.
+- 소매업체가 온체인에서 공급업체에 지불하는 경우, 어떤 관찰자에게든 주문량과 도매 가격을 노출합니다.
+- 재무부가 계정 간에 자금을 이동하면 포지션 규모를 광고합니다.
- 급여 실행은 전체 네트워크에 급여 데이터를 게시합니다.
-완벽한 불투명성(모네로 스타일)은 이 문제를 해결하지만 규정 준수를 위반합니다. 규제 기관과 감사관은 트랜잭션을 확인할 수 없습니다. 선택적 기밀성(금액은 숨겨지고 당사자는 감사 가능)이 Stable이 목표로 하는 모델입니다.
+완전한 불투명성(모네로 스타일)은 이 문제를 해결하지만 규정 준수에 위배됩니다. 규제 기관과 감사자는 트랜잭션을 확인할 수 없습니다. Stable이 목표로 하는 모델은 선택적 기밀성(금액은 숨겨지고, 당사자는 감사 가능)입니다.
## 보이는 것과 보이지 않는 것
-| 필드 | 온체인에서 보이는 요소 | 보호되는 요소 |
+| 필드 | 온체인에서 보임 | 보호됨 |
| :--- | :--- | :--- |
-| 발신자 주소 | ✓ | |
+| 송신자 주소 | ✓ | |
| 수신자 주소 | ✓ | |
| 전송 금액 | | ✓ |
| 보조 메타데이터 | | ✓ |
-보호된 금액은 암호화됩니다. 유효한 증명은 값 자체를 공개하지 않고 전송이 잔액 일관성(인플레이션 없음, 마이너스 금액 없음)을 가진다는 것을 증명합니다. 발신자, 수신자 및 승인된 규제 감사관만 보호된 값을 해독할 수 있습니다.
+보호된 금액은 암호화됩니다. 유효한 증명은 전송이 가치를 공개하지 않고 잔액이 일관됨(인플레이션 없음, 음수 금액 없음)을 증명합니다. 송신자, 수신자, 및 승인된 규제 감사자만이 보호된 값을 해독할 수 있습니다.
## 규정 준수 모델에 적합한 방식
-두 가지 속성은 디자인을 감사 가능하게 만듭니다.
+두 가지 속성이 설계의 감사 가능성을 만듭니다.
-- **결정론적인 감사관 액세스.** 규제 감사관은 관할 구역 내 트랜잭션에 대한 보호된 금액을 해독하는 키를 보유합니다. 임의의 관찰자에 대해 비즈니스 프라이버시는 유지되지만, 규정 준수 조사는 예외입니다.
-- **표준 주소 투명성.** 주소 수준 흐름(제재 확인, 자금 출처 분석)에서 작동하는 AML/KYC 도구는 모든 투명한 체인과 동일한 공개 주소 그래프에 대해 작동합니다.
+- **확정적 감사자 접근.** 규제 감사자는 자신의 관할 구역 내 트랜잭션에 대해 보호된 금액을 해독하는 키를 가지고 있습니다. 무작위 관찰자에 대한 비즈니스 개인정보는 보호되지만, 규정 준수 조사는 보호되지 않습니다.
+- **표준 주소 투명성.** 주소 수준 흐름(제재 확인, 자금 출처 분석)에서 작동하는 AML/KYC 도구는 투명한 체인과 동일한 공개 주소 그래프에 대해 작동합니다.
-## 언제 사용하는가
+## 사용 시점
-기밀 전송은 금액이 상업적으로 민감하지만 상대방이 적절하게 공개되는 모든 흐름에 적합합니다.
+기밀 전송은 금액이 상업적으로 민감하지만 상대방이 적절하게 공개되어야 하는 모든 흐름에 적합합니다.
-- 주문 규모가 가격을 나타내는 공급업체 및 송장 결제.
-- 포지션 규모가 전략을 나타내는 재무 운영.
-- 개별 급여가 경쟁업체에 의해 색인화되어서는 안 되는 급여 지급.
-- 오더북 테이프에 대한 가격 발견이 위험인 대규모 OTC 정산.
+- 주문 크기가 가격을 드러내는 공급업체 및 송장 결제.
+- 포지션 크기가 전략을 드러내는 재무 운영.
+- 개별 급여가 경쟁업체에 의해 인덱싱되어서는 안 되는 급여 지급.
+- 오더북 테이프에 대한 가격 발견이 위험인 대규모 OTC 결제.
-주소 수준 프라이버시도 필요한 흐름(예: 내부 고발자 기부금)의 경우 기밀 전송만으로는 충분하지 않습니다. 이러한 사용 사례에는 Stable이 제공하지 않는 추가 주소 난독화 프리미티브가 필요합니다.
+주소 수준 프라이버시가 필요한 흐름(예: 내부 고발자 기부)의 경우 기밀 전송만으로는 충분하지 않습니다. 이러한 사용 사례에는 Stable이 제공하지 않는 추가 주소 난독화 기본 요소가 필요합니다.
## 상태
-기밀 전송은 개발 중입니다. 타이밍은 [로드맵](/ko/explanation/technical-roadmap)을 참조하십시오. 이 메커니즘은 표준 USDT0 전송과 함께 전용 전송 경로로 출시될 예정입니다. 옵트인하지 않는 기존 애플리케이션은 영향을 받지 않습니다.
+기밀 전송은 개발 중입니다. 일정은 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요. 이 메커니즘은 표준 USDT0 전송과 함께 전용 전송 경로로 출시될 예정입니다. 옵트인하지 않는 기존 애플리케이션은 영향을 받지 않습니다.
## 다음 권장 사항
-- [**USDT를 가스로 활용**](/ko/explanation/usdt-as-gas-token): 기밀 전송이 보호하는 자산 모델을 이해합니다.
-- [**자금 흐름**](/ko/explanation/flow-of-funds): 엔드투엔드 결제 라이프사이클에서 기밀성이 어디에 해당하는지 확인합니다.
-- [**로드맵**](/ko/explanation/technical-roadmap): 기밀 전송이 언제 출시되는지 추적합니다.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): 기밀 전송이 보호하는 자산 모델을 이해하세요.
+- [**자금 흐름**](/ko/explanation/flow-of-funds): 기밀성이 엔드투엔드 결제 라이프사이클에 어떻게 적용되는지 확인하세요.
+- [**로드맵**](/ko/explanation/technical-roadmap): 기밀 전송이 언제 출시되는지 추적하세요.
diff --git a/docs/pages/ko/explanation/eip-7702.mdx b/docs/pages/ko/explanation/eip-7702.mdx
index a1ca0b5..5e4957e 100755
--- a/docs/pages/ko/explanation/eip-7702.mdx
+++ b/docs/pages/ko/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에서 가능하게 하는 것
+## Stable에서 EIP-7702가 제공하는 기능
-EIP-7702를 통해 기존 EOA는 계정 마이그레이션 없이 스마트 계약 로직을 실행할 수 있습니다. Stable의 USDT 중심 결제 환경에서 이는 다음과 같은 패턴을 지원합니다.
+EIP-7702는 기존 EOA가 계정 마이그레이션 없이 스마트 계약 로직을 실행할 수 있도록 합니다. Stable의 USDT 중심 결제 환경에서 다음과 같은 패턴을 지원합니다.
-- **일괄 결제**: 여러 호출(예: 급여 지급 시 여러 수신자에게 지급)이 단일 원자 트랜잭션으로 실행됩니다.
-- **지출 한도**: 위임 계약은 EOA에 대한 일일 한도 또는 트랜잭션당 한도를 강제합니다.
-- **세션 키**: EOA는 소유자의 개인 키를 노출하지 않고 dApp에 범위가 지정되고 시간 제한된 트랜잭션 권한을 부여합니다.
+- **배치 결제**: 여러 호출(예: 급여 지급 시 여러 수신자에게 지급)이 단일 원자적 트랜잭션에서 실행됩니다.
+- **지출 한도**: 위임 계약이 EOA에 대한 일일 상한 또는 트랜잭션당 한도를 강제합니다.
+- **세션 키**: EOA는 소유자의 개인 키를 노출하지 않고 dApp에 범위가 지정된 시간 제한 트랜잭션 권한을 부여합니다.
:::note
-**구현 준비가 되셨나요?** 계약 템플릿, 권한 부여 서명 및 트랜잭션 제출에 대한 [계정 추상화(EIP-7702) 구현 가이드](/ko/reference/eip-7702-api)를 참조하세요.
+**구현 준비 완료?** 계약 템플릿, 승인 서명 및 트랜잭션 제출에 대한 자세한 내용은 [계정 추상화 (EIP-7702) 구현 가이드](/ko/reference/eip-7702-api)를 참조하십시오.
:::
## 작동 방식
-EIP-7702는 `authorizationList`를 포함하는 새로운 트랜잭션 유형(`0x04`)을 도입합니다. 각 권한 부여는 EOA가 해당 트랜잭션에 대해 실행할 코드인 스마트 계약을 지정합니다. 흐름은 다음과 같습니다.
+EIP-7702는 `authorizationList`를 포함하는 새로운 트랜잭션 유형(`0x04`)을 도입합니다. 각 승인은 EOA가 해당 트랜잭션에 대해 실행할 스마트 계약을 지정합니다. 흐름은 다음과 같습니다.
-1. **위임 계약 선택 또는 배포**: EOA가 실행하려는 로직을 구현하는 표준 솔리디티 계약입니다. 기존의 배포된 계약을 사용하거나 직접 배포할 수 있습니다. 가능하면 감사된 계약을 사용하세요.
-2. **권한 부여 서명**: EOA 소유자가 위임 계약을 지정하는 메시지에 서명합니다.
-3. **EIP-7702 트랜잭션 제출**: 트랜잭션에는 권한 부여가 포함되며, EOA는 실행 중에 위임자의 코드를 실행합니다.
+1. **위임 계약 선택 또는 배포**: EOA가 실행하려는 로직을 구현하는 표준 솔리디티 계약. 이미 배포된 계약을 사용하거나 직접 배포할 수 있습니다. 가능한 한 감사된 계약을 사용하십시오.
+2. **승인 서명**: EOA 소유자가 위임 계약을 지정하는 메시지에 서명합니다.
+3. **EIP-7702 트랜잭션 제출**: 트랜잭션에는 승인이 포함되며, EOA는 실행 중에 위임자의 코드를 실행합니다.
-제출 후 EOA의 계정 코드는 위임자로 설정됩니다. 소유자가 위임을 지우거나 교체할 때까지 EOA에 대한 후속 트랜잭션은 위임자의 로직을 실행합니다.
+제출 후, EOA의 계정 코드는 위임자로 설정됩니다. EOA에 대한 후속 트랜잭션은 소유자가 위임을 해제하거나 교체할 때까지 위임자의 로직을 실행합니다.
## 변경되지 않는 사항
-- **새로운 계정 필요 없음**: 사용자는 기존 EOA 주소와 개인 키를 유지합니다. 마이그레이션 단계는 없습니다.
-- **기존 키는 여전히 서명**: EOA의 개인 키는 권한 부여 및 모든 후속 트랜잭션에 서명합니다. EIP-7702는 새로운 서명 체계를 도입하지 않습니다.
-- **표준 EVM 실행**: 위임자는 일반 계약 코드처럼 실행됩니다. 계약 실행을 디버그하거나 추적하는 도구는 변경 없이 작동합니다.
+- **새로운 계정 불필요**: 사용자는 기존 EOA 주소와 개인 키를 유지합니다. 마이그레이션 단계는 없습니다.
+- **기존 키로 계속 서명**: EOA의 개인 키는 승인 및 모든 후속 트랜잭션에 서명합니다. EIP-7702는 새로운 서명 체계를 도입하지 않습니다.
+- **표준 EVM 실행**: 위임자는 일반 계약 코드처럼 실행됩니다. 계약 실행을 디버깅하거나 추적하는 도구는 변경 없이 작동합니다.
## 보안 고려 사항
-- **위임자 접근은 전면적입니다.** 위임 계약은 위임 기간 동안 EOA에 대한 완전한 실행 권한을 가집니다. 위임자 선택을 신뢰 결정으로 다루세요. 악의적인 위임자는 자산을 고갈시킬 수 있습니다.
-- **위임은 지속됩니다.** 단일 트랜잭션으로 만료되지 않습니다. 소유자는 더 이상 원하지 않을 때 위임을 명시적으로 지우거나 교체해야 합니다.
-- **가스 비용은 약간 높습니다.** 권한 부여 처리로 인해 약간 높지만, 위임자가 여러 호출을 일괄 처리할 때 상쇄됩니다. 기본 수수료가 1 gwei이고 가스가 USDT0으로 표시되는 Stable에서는 추가 권한 부여 오버헤드가 1센트 미만으로 유지되며, 비용 면에서 표준 ERC-20 전송과 비슷합니다.
+- **위임자 접근은 전적입니다.** 위임 계약은 위임 기간 동안 EOA에 대한 완전한 실행 권한을 가집니다. 위임자 선택을 신뢰 결정으로 다루십시오. 악의적인 위임자는 자산을 고갈시킬 수 있습니다.
+- **위임은 지속됩니다.** 단일 트랜잭션이 끝난다고 만료되지 않습니다. 소유자는 더 이상 위임을 원하지 않을 때 명시적으로 위임을 해제하거나 교체해야 합니다.
+- **가스 비용은 약간 더 높습니다.** 승인 처리로 인해 가스 비용이 약간 더 높지만, 위임자가 여러 호출을 일괄 처리할 때 상쇄됩니다. Stable에서 기본 수수료는 1 gwei이고 가스는 USDT0로 표시되므로 추가 승인 오버헤드는 1센트 미만으로 유지되며, 표준 ERC-20 전송과 비슷한 비용입니다.
## 다음 권장 사항
-- [**계정 추상화(EIP-7702)**](/ko/reference/eip-7702-api): 위임 계약에 대해 일괄 결제, 지출 한도 및 세션 키를 구현하세요.
-- [**가스 토큰으로서의 USDT**](/ko/explanation/usdt-as-gas-token): EIP-7702 트랜잭션이 실행되는 가스 모델을 이해하세요.
-- [**가스 면제**](/ko/explanation/gas-waiver): 위임을 애플리케이션이 사용자 가스를 대신 지불하는 가스 면제 흐름과 비교하세요.
+- [**계정 추상화 (EIP-7702)**](/ko/reference/eip-7702-api): 위임 계약에 대해 배치 결제, 지출 한도 및 세션 키를 구현합니다.
+- [**USDT0를 가스로 사용**](/ko/explanation/usdt-as-gas-token): EIP-7702 트랜잭션이 실행되는 가스 모델을 이해합니다.
+- [**가스 면제**](/ko/explanation/gas-waiver): 애플리케이션이 사용자 가스를 대신 지불하는 가스 면제 흐름과 위임 방식을 비교합니다.
diff --git a/docs/pages/ko/explanation/erc-3009.mdx b/docs/pages/ko/explanation/erc-3009.mdx
index 0d935b6..83ccf85 100644
--- a/docs/pages/ko/explanation/erc-3009.mdx
+++ b/docs/pages/ko/explanation/erc-3009.mdx
@@ -1,98 +1,98 @@
---
source_path: explanation/erc-3009.mdx
-source_sha: 355aa51b2e83bc01b1345eb0ec5d437956854d01
-title: "서명된 승인으로 정산"
-description: "직접적인 계약 호출 없이 메시지 서명을 통해 토큰 이체를 승인합니다. ERC-3009는 Stable의 x402 결제 뒤에 있는 정산 메커니즘입니다."
+source_sha: b8359b8c523fa0b88e18a1672228e6cd45f59dfc
+title: "서명된 승인으로 결제"
+description: "직접적인 컨트랙트 호출 없이 메시지에 서명하여 토큰 전송을 승인합니다. ERC-3009는 Stable의 x402 결제 뒤에 있는 결제 메커니즘입니다."
diataxis: "explanation"
---
-# 서명된 승인으로 정산
+# 서명된 승인으로 결제
-ERC-3009는 토큰 보유자가 메시지에 서명하여 이체를 승인할 수 있도록 합니다. 그러면 누구나 서명된 승인을 제출하여 온체인으로 이체를 실행할 수 있습니다. 발신자는 계약을 직접 호출할 필요가 없습니다.
+ERC-3009는 토큰 보유자가 메시지에 서명하여 전송을 승인할 수 있도록 합니다. 그러면 누구나 서명된 승인을 제출하여 온체인에서 전송을 실행할 수 있습니다. 발신자는 컨트랙트를 직접 호출할 필요가 없습니다.
-이는 Stable의 [x4402](/ko/explanation/x402) 결제 뒤에 있는 정산 메커니즘입니다.
+이것은 Stable의 [x402](/ko/explanation/x402) 결제 뒤에 있는 결제 메커니즘입니다.
## 어떤 문제를 해결하나요?
### 허용 문제
-서드파티 이체를 위한 기존 ERC-20 패턴은 `approve` + `transferFrom`입니다. 발신자는 먼저 `approve`를 호출하여 사용 허가를 부여한 다음, 서드파티가 `transferFrom`을 호출하여 자금을 이동합니다. 여기에는 잘 알려진 문제가 있습니다.
+제3자 전송을 위한 전통적인 ERC-20 패턴은 `approve` + `transferFrom` 입니다. 발신자는 먼저 `approve`를 호출하여 지출 허용량을 부여한 다음, 제3자가 `transferFrom`을 호출하여 자금을 이동합니다. 여기에는 잘 알려진 문제가 있습니다.
-- **두 번의 트랜잭션 필요**: 이체가 발생하기 전에 발신자는 온체인 `approve` 트랜잭션을 보내야 합니다. 이는 가스를 소모하고 지연 시간을 추가합니다.
-- **무한 허용 위험**: 반복적인 승인 트랜잭션을 피하기 위해 많은 애플리케이션은 무제한 사용 권한을 요청하여 상당한 보안 위험을 발생시킵니다.
+- **두 번의 트랜잭션 필요**: 발신자는 전송이 발생하기 전에 온체인 `approve` 트랜잭션을 보내야 합니다. 이는 가스 비용을 발생시키고 지연을 추가합니다.
+- **무한 허용 위험**: 반복되는 승인 트랜잭션을 피하기 위해 많은 애플리케이션은 무제한 지출 권한을 요청하여 상당한 보안 위험을 초래합니다.
-ERC-3009는 다른 접근 방식을 취합니다. 허용을 부여하는 대신 발신자는 특정 이체에 대한 일회성 승인에 서명합니다. 별도의 승인 단계도 없고, 남아있는 사용 권한도 없습니다.
+ERC-3009는 다른 접근 방식을 취합니다. `allowance`를 부여하는 대신, 발신자는 특정 전송에 대한 일회성 승인에 서명합니다. 별도의 승인 단계도 없고, 남아 있는 지출 권한도 없습니다.
### 순차 논스 문제
-ERC-2612(`permit`)도 서명된 승인을 가능하게 하지만, 순차 논스를 사용합니다. 여러 허가(permit)는 순서 종속성을 가집니다. 논스 5가 소비되지 않으면 논스 6은 절대 실행될 수 없습니다.
+ERC-2612 (`permit`)도 서명된 승인을 가능하게 하지만, 순차 논스를 사용합니다. 여러 `permit`은 순서 종속성을 가집니다. 논스 5가 사용되지 않으면 논스 6은 절대 실행될 수 없습니다.
-ERC-3009는 **고유 논스**로 이 문제를 해결합니다. 각 승인은 순차 카운터 대신 32바이트 값을 사용합니다. 여러 승인을 서로 독립적으로, 어떤 순서로든 생성하고 제출할 수 있습니다.
+ERC-3009는 **고유 논스**로 이 문제를 해결합니다. 각 승인은 순차 카운터 대신 32바이트 값을 사용합니다. 여러 승인은 서로 의존하지 않고 어떤 순서로든 독립적으로 생성되고 제출될 수 있습니다.
### 비교
| **속성** | **ERC-20** (`approve`) | **ERC-2612** (`permit`) | **ERC-3009** |
| :--- | :--- | :--- | :--- |
| 온체인 단계 | 2 (`approve` + `transferFrom`) | 1 (`transferFrom`) | 1 (`transferWithAuthorization`) |
-| 허용 모델 사용 | 필요 (온체인 트랜잭션) | 예 (`permit`을 통해 허용 설정) | 필요 없음 (서명) |
+| 허용 모델 사용 | 필요 (온체인 트랜잭션) | 예 (`permit`을 통해 허용량 설정) | 필요 없음 (서명) |
| 논스 모델 | 순차 | 순차 | 고유 |
-| 동시 승인 | 아니요 | 아니요 | 예 |
+| 동시 승인 | 아니오 | 아니오 | 예 |
## 작동 방식
### transferWithAuthorization
-발신자는 이체 세부 정보를 포함하는 EIP-712 형식의 데이터 메시지에 서명합니다. 그러면 누구나 해당 서명된 메시지로 토큰 컨트랙트에서 `transferWithAuthorization`을 호출할 수 있습니다. 컨트랙트는 서명을 확인하고, 유효 기간을 확인하며, 이체를 실행하고, 논스를 사용된 것으로 표시합니다.
+발신자는 전송 세부 정보가 포함된 EIP-712 유형 데이터 메시지에 서명합니다. 그러면 누구나 해당 서명된 메시지로 토큰 컨트랙트에서 `transferWithAuthorization`을 호출할 수 있습니다. 컨트랙트는 서명을 확인하고, 유효 기간을 확인하고, 전송을 실행하고, 논스를 사용된 것으로 표시합니다.
서명된 승인에는 다음이 포함됩니다.
- `from`: 발신자(서명자)의 주소
- `to`: 수신자의 주소
-- `value`: 이체 금액
-- `validAfter`: 이 승인을 실행할 수 있는 가장 이른 시간 (Unix 타임스탬프)
-- `validBefore`: 이 승인을 실행할 수 있는 가장 늦은 시간 (Unix 타임스탬프)
+- `value`: 전송 금액
+- `validAfter`: 이 승인이 실행될 수 있는 가장 빠른 시간 (Unix 타임스탬프)
+- `validBefore`: 이 승인이 실행될 수 있는 가장 늦은 시간 (Unix 타임스탬프)
- `nonce`: 고유성을 보장하는 32바이트 값
-시간 창(`validAfter`/`validBefore`)을 통해 발신자는 이체가 발생할 수 있는 시점을 정확하게 제어할 수 있습니다. 승인을 미래로 예약하거나, 마감일을 정하거나, 이 둘 다를 수행할 수 있습니다. 제출 전에 창이 만료되면 승인은 유효하지 않게 되며 자금은 발신자에게 남아 있습니다.
+시간 창 (`validAfter`/`validBefore`)을 통해 발신자는 전송이 언제 발생할 수 있는지 정확하게 제어할 수 있습니다. 승인을 미래로 예약하거나, 기한을 정하거나, 둘 다 할 수 있습니다. 제출 전에 창이 만료되면 승인이 무효화되고 자금은 발신자에게 남습니다.
### receiveWithAuthorization
-이 함수는 `transferWithAuthorization`과 동일하게 작동하지만, 한 가지 추가 확인이 있습니다. **호출자는 수신자여야 합니다**. 이는 서드파티가 보류 중인 승인을 관찰하고 먼저 제출하여 트랜잭션 순서를 조작하는 선행 공격을 방지합니다.
+이 함수는 `transferWithAuthorization`과 동일하게 작동하며, 한 가지 추가 확인 사항이 있습니다. **호출자는 수신자여야 합니다**. 이는 제3자가 보류 중인 승인을 관찰하고 트랜잭션 순서를 조작하기 위해 먼저 제출하는 선행 공격을 방지합니다.
-이것은 수신자(판매자 또는 서비스 제공업체)가 정산을 시작해야 하는 결제 시나리오에서 유용합니다.
+이것은 수신자(판매자 또는 서비스 제공업체)가 결제 시작을 담당해야 하는 결제 시나리오에서 유용합니다.
### cancelAuthorization
-발신자는 실행되기 전에 사용되지 않은 승인을 철회할 수 있습니다. 발신자는 EIP-712 취소 메시지에 서명하고, 컨트랙트는 이체를 실행하지 않고 논스를 사용된 것으로 표시합니다. 원래 승인은 더 이상 제출될 수 없습니다.
+발신자는 사용되지 않은 승인이 실행되기 전에 취소할 수 있습니다. 발신자는 EIP-712 취소 메시지에 서명하고, 컨트랙트는 전송을 실행하지 않고 논스를 사용된 것으로 표시합니다. 원래 승인은 더 이상 제출될 수 없습니다.
## 내장된 안전 속성
- **일회성 사용**: 각 고유 논스는 한 번만 사용할 수 있습니다. 동일한 서명된 승인을 다시 제출하면 되돌려집니다.
- **시간 제한**: `validAfter`/`validBefore` 창은 승인이 무기한 유효하지 않도록 보장합니다.
-- **자율성**: 하나의 서명은 하나의 특정 수신자에게 특정 금액의 하나의 특정 이체를 승인합니다. 남아있는 권한이 없습니다.
-- **비수탁**: 제출자는 발신자의 자금을 절대 보유하지 않습니다. 이체는 컨트랙트 내에서 발신자에서 수신자로 직접 이동합니다.
+- **자립적**: 하나의 서명은 하나의 특정 수신자에게 하나의 특정 금액의 하나의 특정 전송을 승인합니다. 남아 있는 권한은 없습니다.
+- **비수탁형**: 제출자는 발신자의 자금을 절대 보유하지 않습니다. 전송은 컨트랙트 내에서 발신자에서 수신자로 직접 이동합니다.
## Stable의 ERC-3009
Stable의 USDT0은 ERC-3009를 기본적으로 구현합니다. 어떤 애플리케이션이든 추가 컨트랙트나 릴레이 인프라를 배포할 필요 없이 `transferWithAuthorization`을 사용할 수 있습니다.
-### 단일 자산 정산
+### 단일 자산 결제
-이더리움에서는 ERC-3009를 사용하더라도 제출자는 `transferWithAuthorization`을 호출하기 위해 가스를 지불할 ETH가 필요합니다. 이체 자체는 USDT로 이루어지지만, 실행은 별도의 기본 자산에 의존합니다.
+이더리움에서는 ERC-3009를 사용하더라도 제출자는 `transferWithAuthorization`을 호출하기 위해 가스 비용으로 ETH가 필요합니다. 전송 자체는 USDT로 이루어지지만, 실행은 별도의 기본 자산에 의존합니다.
-Stable에서는 USDT0이 결제 토큰과 가스 토큰 역할을 모두 합니다. 승인부터 온체인 정산까지 전체 결제 수명 주기가 단일 스테이블코인으로 실행됩니다. 어떤 단계에서도 별도의 기본 자산이 필요하지 않습니다.
+Stable에서는 USDT0이 결제 토큰과 가스 토큰 역할을 모두 합니다. 승인부터 온체인 결제까지 전체 결제 수명 주기가 단일 스테이블코인으로 실행됩니다. 어떤 단계에서도 별도의 기본 자산이 필요하지 않습니다.
-이러한 특성 덕분에 Stable의 ERC-3009는 고수준 결제 프로토콜의 강력한 기반이 됩니다. [x402](/ko/explanation/x402)는 이를 직접 활용하여, 표준 HTTP 통신 내에서 ERC-3009를 온체인 정산 메커니즘으로 사용합니다.
+이 속성 덕분에 Stable의 ERC-3009는 고수준 결제 프로토콜의 강력한 기반이 됩니다. [x402](/ko/explanation/x402)는 이를 직접 활용하여 표준 HTTP 통신 내에서 ERC-3009를 온체인 결제 메커니즘으로 사용합니다.
-## 핵심 요점
+## 주요 내용
-- ERC-3009는 토큰 보유자가 메시지에 서명하여 이체를 승인할 수 있도록 합니다. 누구나 서명된 승인을 제출하여 이체를 실행할 수 있습니다.
-- 이는 ERC-20 허용 모델을 일회성, 자율적 승인으로 대체합니다. `approve` 단계도, 남아있는 권한도, 이중 지불 위험도 없습니다.
-- 고유 논스는 여러 승인을 어떤 순서로든 동시에 생성하고 제출할 수 있도록 합니다.
-- Stable의 USDT0은 ERC-3009를 기본적으로 지원하며, USDT0만으로 정산을 완료할 수 있으므로 x402의 실용적인 기반을 제공합니다.
+- ERC-3009는 토큰 보유자가 메시지에 서명하여 전송을 승인할 수 있도록 합니다. 누구나 서명된 승인을 제출하여 전송을 실행할 수 있습니다.
+- ERC-20 허용 모델을 일회성으로 사용되는 자립형 승인으로 대체합니다. `approve` 단계, 남아 있는 권한, 이중 지불 위험이 없습니다.
+- 고유 논스를 통해 여러 승인을 어떤 순서로든 동시에 생성하고 제출할 수 있습니다.
+- Stable의 USDT0은 ERC-3009를 기본적으로 지원하며, USDT0만으로 결제가 완료될 수 있으므로 x402의 실용적인 기반을 제공합니다.
-**참고:**
+**참고 항목:**
-- [가스 토큰으로서의 USDT](/ko/explanation/usdt-as-gas-token)
-- [Stable에서의 USDT0 동작 방식](/ko/explanation/usdt0-behavior)
-- [x402 (HTTP-원시 결제)](/ko/explanation/x402)
+- [가스로서의 USDT0](/ko/explanation/usdt-as-gas-token)
+- [Stable에서의 USDT0 동작](/ko/explanation/usdt0-behavior)
+- [x402 (HTTP-Native 결제)](/ko/explanation/x402)
diff --git a/docs/pages/ko/explanation/ethereum-comparison.mdx b/docs/pages/ko/explanation/ethereum-comparison.mdx
index 3a826fc..75f3b21 100644
--- a/docs/pages/ko/explanation/ethereum-comparison.mdx
+++ b/docs/pages/ko/explanation/ethereum-comparison.mdx
@@ -1,81 +1,81 @@
---
source_path: explanation/ethereum-comparison.mdx
-source_sha: 899ef035bfd583ce5d1f14916e2dbd9df613a7bb
+source_sha: a54f9794aff02779e52e91631c6447116a7800a4
title: "이더리움 비교"
-description: "Stable은 완전한 EVM 호환성을 제공합니다. 이더리움에서 포팅할 때 변경되지 않는 사항, 변경되는 사항, 주의해야 할 사항을 설명합니다."
+description: "Stable은 완벽하게 EVM과 호환됩니다. Ethereum에서 포팅할 때 무엇이 동일하게 유지되고, 무엇이 변경되며, 무엇을 주의해야 할까요?"
diataxis: "explanation"
---
# 이더리움 비교
-Stable은 완전한 EVM 호환성을 제공하므로 대부분의 이더리움 도구, 라이브러리 및 계약 패턴은 수정 없이 작동합니다. 다음 섹션에서는 이더리움에서 Stable로 전환할 때 변경되지 않는 사항과 변경되는 사항을 설명합니다.
+Stable은 완벽하게 EVM과 호환되므로 대부분의 이더리움 도구, 라이브러리 및 컨트랙트 패턴은 수정 없이 작동합니다. 아래 섹션에서는 Ethereum에서 Stable로 전환할 때 무엇이 동일하게 유지되고 무엇이 변경되는지 설명합니다.
-## 변경되지 않는 사항
+## 동일하게 유지되는 사항
-Stable은 이더리움 개발 생태계와 완벽한 호환성을 유지합니다.
+Stable은 이더리움 개발 생태계와 완벽한 호환성을 유지합니다:
| **영역** | **호환성** |
| :--- | :--- |
| 언어 | Solidity, Vyper |
-| 툴링 | Hardhat, Foundry |
+| 도구 | Hardhat, Foundry |
| 라이브러리 | ethers.js, web3.js |
-| 계약 패턴 | 모든 표준 EVM 컨벤션 (ERC-20, ERC-721, ERC-1155, 프록시 등) |
+| 컨트랙트 패턴 | 모든 표준 EVM 컨벤션 (ERC-20, ERC-721, ERC-1155, 프록시 등) |
| RPC 인터페이스 | 대부분의 `eth_*` 메서드 지원 (`eth_call`, `eth_sendRawTransaction`, `eth_getBalance`, `eth_getLogs`, `eth_estimateGas` 등). 전체 목록은 [JSON-RPC API](/ko/reference/json-rpc-api) 참조 |
-기존 스마트 계약, 배포 스크립트 및 프론트엔드 통합은 RPC 엔드포인트와 체인 ID를 변경하여 Stable을 대상으로 합니다.
+기존 스마트 컨트랙트, 배포 스크립트 및 프론트엔드 통합은 RPC 엔드포인트 및 체인 ID를 변경하여 Stable을 대상으로 합니다.
## 다른 점
-이더리움과 네 가지 동작이 다릅니다.
+네 가지 동작이 이더리움과 다릅니다.
### 1. 단일 슬롯 완결성
-이더리움은 트랜잭션이 최종으로 간주되기 전에 여러 블록 확인이 필요합니다. Stable은 단일 슬롯 완결성을 제공합니다. 즉, 트랜잭션은 블록에 포함되는 즉시 최종이 됩니다.
+이더리움은 트랜잭션이 최종 확정된 것으로 간주되기 전에 여러 블록 확인이 필요합니다. Stable은 단일 슬롯 완결성을 제공합니다. 트랜잭션은 블록에 포함되는 즉시 최종 확정됩니다.
-개발자를 위한 의미는 다음과 같습니다.
+개발자의 경우 다음을 의미합니다.
-- 트랜잭션이 확인된 블록에 나타나면 해당 상태 변경은 최종적이며 되돌릴 수 없습니다.
-- 애플리케이션은 결제 확인 수단으로 블록 포함에 안전하게 의존할 수 있습니다.
+- 트랜잭션이 확인된 블록에 나타나면 상태 변경은 최종적이며 되돌릴 수 없습니다.
+- 애플리케이션은 결제 확인으로 블록 포함에 안전하게 의존할 수 있습니다.
-확정적 완결성을 갖추고 있음에도 불구하고, 재정적으로 민감한 흐름을 처리하는 애플리케이션은 다음을 수행해야 합니다.
+확정적 완결성이 있더라도, 재정적으로 민감한 흐름을 처리하는 애플리케이션은 다음을 수행해야 합니다.
-- 종속 작업(예: 잠금 해제, 상환)을 진행하기 전에 RPC 또는 발생한 이벤트를 통해 트랜잭션 성공을 확인합니다.
-- 자동화 및 배치 작업을 위해 재시도 및 조정 로직을 구현하여 일시적인 제출 또는 RPC 오류를 처리합니다.
+- 종속 작업 (예: 잠금 해제, 상환)을 진행하기 전에 RPC 또는 발생된 이벤트를 통해 트랜잭션 성공을 확인합니다.
+- 자동화 및 배치 작업을 위한 재시도 및 조정 로직을 구현하여 일시적인 제출 또는 RPC 오류를 처리합니다.
### 2. 가스 토큰: USDT0
-Stable에서는 이더리움 블록체인에서 ETH로 가스를 결제하는 방식과 유사하게, USDT0로 거래 수수료를 지불합니다. 이는 USDT 단위로 예측 가능한 낮은 가스 비용을 제공합니다.
+Stable에서 트랜잭션 수수료는 변동성이 있는 네이티브 토큰이 아닌 USDT0으로 지불됩니다. 이는 USDT 기반의 예측 가능한 낮은 가스 비용을 제공합니다.
-- 사용자는 거래를 제출하려면 지갑에 USDT0를 보유해야 합니다.
-- 거래의 `value` 필드는 이더리움에서 ETH를 보내는 방식과 유사하게 USDT0를 보내는 데 계속 작동합니다.
-- 자세한 내용은 [가스 지불 수단으로서의 USDT](/ko/explanation/usdt-as-gas-token)를 참조하십시오.
+- 사용자는 USDT0을 지갑에 가지고 있어야 트랜잭션을 제출할 수 있습니다.
+- 트랜잭션의 `value` 필드는 USDT0을 보내는 데 여전히 작동하며, 이더리움에서 ETH를 보내는 것과 유사합니다.
+- 자세한 내용은 [가스로서의 USDT0](/ko/explanation/usdt-as-gas-token)을 참조하십시오.
-### 3. 우선순위 팁 없음
+### 3. 우선 순위 팁 없음
Stable은 단일 구성 요소 가스 모델을 사용합니다. 팁 기반 트랜잭션 순서 지정은 없습니다.
-- `maxPriorityFeePerGas`는 무시됩니다(항상 0).
-- 트랜잭션 순서는 수수료 입찰의 영향을 받지 않습니다.
-- 지갑은 우선순위 팁 입력 필드를 숨기거나 비활성화해야 합니다.
+- `maxPriorityFeePerGas`는 무시됩니다 (항상 0).
+- 트랜잭션 순서 지정은 수수료 입찰의 영향을 받지 않습니다.
+- 지갑은 우선 순위 팁 입력 필드를 숨기거나 비활성화해야 합니다.
- 자세한 내용은 [가스 가격 책정](/ko/explanation/gas-pricing)을 참조하십시오.
### 4. USDT0 이중 역할 동작
-USDT0는 네이티브 가스 토큰이자 ERC-20 토큰으로 기능합니다. 이로 인해 잔액 의미론, 허용 안전성 및 특정 opcode 가정에 대한 행동 차이가 발생합니다. 자세한 내용은 [Stable에서의 USDT0 동작](/ko/explanation/usdt0-behavior)을 참조하십시오.
+USDT0은 기본 가스 토큰이자 ERC-20 토큰으로 기능합니다. 이는 잔액 의미 체계, 허용 안전성 및 특정 opcode 가정과 관련된 동작 차이를 발생시킵니다. 자세한 내용은 [Stable에서의 USDT0 동작](/ko/explanation/usdt0-behavior)을 참조하십시오.
## 빠른 비교
-| **매개변수** | **Stable** | **이더리움** |
+| **파라미터** | **Stable** | **이더리움** |
| :--- | :--- | :--- |
| 가스 토큰 | USDT0 | ETH |
| 완결성 | 단일 슬롯 | 다중 블록 확인 |
-| 블록 타임 | ~0.7 초 | ~12 초 |
-| 우선순위 팁 (`maxPriorityFeePerGas`) | 무시됨 (항상 0) | 순서 지정을 위해 사용됨 |
+| 블록 타임 | ~0.7초 | ~12초 |
+| 우선 순위 팁 (`maxPriorityFeePerGas`) | 무시됨 (항상 0) | 순서 지정에 사용됨 |
| EIP-1559 트랜잭션 형식 | 지원됨 | 지원됨 |
| EVM 호환성 | 완전 | N/A |
-## 다음 권장 사항
+## 다음 추천 항목
-- [**가스 지불 수단으로서의 USDT**](/ko/explanation/usdt-as-gas-token): 이더리움을 대체하는 자산 모델을 이해하세요.
-- [**가스 가격 책정**](/ko/explanation/gas-pricing): 단일 구성 요소 수수료 모델을 자세히 검토하세요.
-- [**Stable에서의 USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 자산 의미론, 허용 안전성 및 `EXTCODEHASH` 동작에 대해 계약을 감사하세요.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): ETH를 대체하는 가스 자산 모델을 이해합니다.
+- [**가스 가격 책정**](/ko/explanation/gas-pricing): 단일 구성 요소 수수료 모델을 자세히 검토합니다.
+- [**Stable에서의 USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 자산 의미 체계, 허용 안전성 및 `EXTCODEHASH` 동작에 대해 컨트랙트를 감사합니다.
diff --git a/docs/pages/ko/explanation/flow-of-funds.mdx b/docs/pages/ko/explanation/flow-of-funds.mdx
index 3fc94a8..898a2f5 100644
--- a/docs/pages/ko/explanation/flow-of-funds.mdx
+++ b/docs/pages/ko/explanation/flow-of-funds.mdx
@@ -1,67 +1,67 @@
---
source_path: explanation/flow-of-funds.mdx
-source_sha: cfc1ee60f37976af8099cec9efcea804bfab0f15
+source_sha: a5cf76cc30ee47cc0f9e164a9419bf68d2e388ac
title: "자금 흐름"
-description: "Stable에서 USDT의 엔드투엔드 라이프사이클(온-램프부터 온체인 전송, 오프-램프 결제까지)."
+description: "Stable에서의 USDT의 엔드투엔드 라이프사이클 — 온램프부터 온체인 전송, 그리고 오프램프 정산까지."
diataxis: "explanation"
---
# 자금 흐름
-Stable은 스테이블코인 결제를 위해 특별히 구축된 최초의 블록체인입니다. 이 네트워크는 고 처리량, 낮은 지연 시간의 스테이블코인 거래에 최적화되어 있으며, USDT로 즉시 결제되는 P2P 지불 및 가맹점 수락을 제공합니다. 애플리케이션 계층 가스 스폰서십 및 면제를 통해 제공업체는 최종 사용자에게 수수료 없는 경험을 제공하여 블록체인 시스템의 복잡성을 추상화하는 동시에 주류 결제 네트워크 느낌을 제공할 수 있습니다.
+Stable은 스테이블코인 결제를 위해 특별히 구축된 최초의 블록체인입니다. 이 네트워크는 처리량이 많고 대기 시간이 짧은 스테이블코인 거래에 최적화되어, USDT로 즉시 정산되는 P2P 결제 및 가맹점 결제를 제공합니다. 애플리케이션 계층 가스 후원 및 면제를 통해 제공업체는 최종 사용자에게 수수료 없는 경험을 제공하여 블록체인 시스템의 복잡성을 추상화하면서도 주류 결제 네트워크 느낌을 줍니다.
-이 페이지에서는 Stable에서의 자금의 전체 라이프사이클을 설명합니다. USDT가 네트워크에 어떻게 진입하고, 참여자 간에 이동하며, 다시 법정화폐로 전환되는지 보여줍니다.
+이 페이지에서는 Stable에서의 자금 라이프사이클 전체를 설명합니다: USDT가 네트워크에 어떻게 진입하고, 참여자 간에 이동하며, 다시 법정화폐 레일로 출금되는지.
-## 1. 고객 예치 (온-램프)
+## 1. 고객 예치금 (온램프)
-사용자는 다음 세 가지 주요 채널 중 하나를 통해 네트워크에 돈을 가져옵니다.
+사용자는 다음 세 가지 주요 채널 중 하나를 통해 네트워크에 자금을 가져옵니다:
-- **암호화폐 전송**: 주요 암호화폐는 Stable에서 USDT0로 브리지되거나 변환됩니다. USDT0는 USDT의 옴니체인 표준이자 네트워크의 주요 형태입니다.
-- **법정화폐 온-램프**: 카드, ACH 또는 지역 결제 방법으로 법정화폐를 USDT0로 변환하여 사용자의 지갑으로 직접 전달합니다.
-- **CEX 출금**: 사용자는 지원되는 중앙화된 거래소에서 USDT를 출금하고, Stable을 목적지 네트워크로 선택합니다. 거래소는 사용자의 지갑으로 직접 결제를 완료합니다.
+- **암호화폐 전송**: 주요 암호화폐는 Stable의 USDT0로 브릿지되거나 변환됩니다. USDT0는 USDT의 옴니체인 표준이며 네트워크의 기본 형태입니다.
+- **법정화폐 온램프**: 카드, ACH 또는 현지 결제 수단으로 법정화폐를 USDT0로 변환하여 사용자 지갑으로 직접 전달됩니다.
+- **CEX 출금**: 사용자가 지원하는 중앙화 거래소에서 USDT를 출금할 때 Stable을 목적지 네트워크로 선택합니다. 거래소는 사용자 지갑으로 직접 정산합니다.
-모든 경우에 최종 상태는 동일합니다. 사용자의 지갑은 Stable에서 USDT (USDT0 형태)를 직접 보유합니다.
+모든 경우 최종 상태는 동일합니다: 사용자의 지갑은 Stable에서 직접 USDT (USDT0)를 보유합니다.
-## 2. P2P / 가맹점 전송 (온체인 지불)
+## 2. P2P / 판매자 전송 (온체인 페이인)
-자금이 Stable에 있으면 고객은 USDT를 다른 사용자나 가맹점으로 직접 보냅니다. 온체인 전송의 주요 특징:
+자금이 Stable에 있으면 고객은 USDT를 다른 사용자나 판매자에게 직접 보냅니다. 온체인 전송의 주요 특징:
-- **즉시 결제**: 전송은 온체인에서 즉시 결제됩니다.
-- **비수탁**: 비수탁 지갑의 경우, PSP 또는 중개자는 송수신 간에 사용자 잔액을 전혀 건드리지 않습니다.
-- **단일 자산**: USDT가 가스와 결제 자산 둘 다이기 때문에 흐름에 추가 토큰이 없고 숨겨진 스프레드가 없습니다.
-- **제로 가스 옵션**: 가스 면제를 통해 최종 사용자는 블록체인 수수료를 관리할 필요 없이 자금을 이동할 수 있습니다. 자세한 내용은 [가스 면제](/ko/reference/gas-waiver-api)를 참조하십시오.
+- **즉시 정산**: 전송은 온체인에서 즉시 정산됩니다.
+- **비수탁**: 비수탁 지갑의 경우, PSP 또는 중개자는 소스와 목적지 사이에서 사용자 잔액을 전혀 건드리지 않습니다.
+- **단일 자산**: USDT가 가스와 정산 자산 모두이기 때문에 흐름에 추가 토큰이 없으며 숨겨진 스프레드가 없습니다.
+- **가스 제로 옵션**: 가스 면제를 통해 최종 사용자는 블록체인 수수료를 관리할 필요 없이 자금을 이동할 수 있습니다. 자세한 내용은 [가스 면제](/ko/reference/gas-waiver-api)를 참조하십시오.
-## 3. 사용자 / 가맹점 잔액
+## 3. 사용자 / 판매자 잔액
-가맹점은 자신의 직접 통제하에 Stable 지갑으로 USDT를 받습니다. 자금은 사용자 또는 가맹점의 수중에 온체인으로 보관됩니다. 이 지갑은 사용자를 대신하여 결제 제공업체가 생성하고 관리할 수 있습니다.
+판매자는 자신의 직접적인 통제 하에 Stable 지갑에서 USDT를 받습니다. 자금은 사용자 또는 판매자의 보관 하에 온체인에 보관됩니다. 이러한 지갑은 결제 제공업체가 사용자를 대신하여 생성하고 관리할 수 있습니다.
-## 4. 가맹점 출금 (오프-램프 / 지급)
+## 4. 판매자 출금 (오프램프 / 지불)
-가맹점 또는 사용자가 오프체인 법정화폐 결제를 요청할 때:
+판매자 또는 사용자가 오프체인 법정화폐 정산을 요청할 때:
-1. 제공업체는 뱅킹 또는 결제 레일을 통해 전환(USDT → 법정화폐)을 시작합니다.
-2. 자금은 가맹점이 선택한 계정으로 입금됩니다.
+1. 제공업체는 뱅킹 또는 지급 레일을 통해 전환(USDT → 법정화폐)을 시작합니다.
+2. 자금은 판매자가 선택한 계정으로 입금됩니다.
-제공업체는 가맹점을 현금화하기 위해서만 흐름에 다시 참여하며, 생태계 내 전송 중에는 참여하지 않습니다. 일상적인 P2P 흐름은 중개가 필요하지 않습니다. 제공업체는 예치(가맹점 계정으로 USDT 전송) 또는 출금(USDT → 법정화폐) 시에만 참여합니다.
+제공업체는 판매자에게 현금을 인출할 때만 흐름에 다시 참여하며, 생태계 내 전송 중에는 참여하지 않습니다. 일상적인 P2P 흐름에는 중개가 필요하지 않습니다. 제공업체는 예치(USDT를 판매자 계정으로 전송) 또는 출금(USDT → 법정화폐) 시에만 참여합니다.
## 교차 자산 거래
-Stable은 또한 지불자가 USDT0가 아닌 암호화폐를 보유하는 시나리오도 지원합니다.
+Stable은 또한 지불자가 USDT가 아닌 암호화폐를 보유하는 시나리오를 지원합니다.
### 사용자가 다른 암호화폐로 거래
-사용자는 통합된 거래소, 브로커 또는 온체인 DEX를 통해 다른 암호화폐(예: BTC 또는 ETH)를 보유하거나 거래할 수 있습니다. 지불 시 시스템은 선택된 암호화폐를 USDT로 자동 변환하고, 그 다음 가맹점의 Stable 지갑으로 전송됩니다. 사용자의 선호 자산과 관계없이 모든 온체인 결제는 USDT로 계속 이루어집니다.
+사용자는 통합 거래소, 브로커 또는 온체인 DEX를 통해 다른 암호화폐(예: BTC 또는 ETH)를 보유하거나 거래할 수 있습니다. 결제 시 시스템은 선택된 암호화폐를 자동으로 USDT로 변환한 다음 판매자의 Stable 지갑으로 전송합니다. 사용자의 선호 자산에 관계없이 모든 온체인 정산은 USDT로 계속 이루어집니다.
-### 가맹점의 암호화폐 결제 수락
+### 판매자의 암호화폐 결제 수락
-가맹점은 여러 암호화폐를 직접 수락하거나 관리할 필요가 없습니다. 그들은 항상 Stable 지갑에 USDT로 입금되어 네트워크 전체에서 단일 결제 통화를 유지합니다. 이 설계는 가맹점의 FX 노출을 최소화하고 조정 및 보고를 단순화합니다.
+판매자는 여러 암호화폐를 직접 수락하거나 관리할 필요가 없습니다. 판매자는 항상 Stable 지갑에 USDT로 입금되며, 네트워크 전체에서 단일 정산 통화를 유지합니다. 이 설계는 판매자의 환율 노출을 최소화하고 조정 및 보고를 단순화합니다.
### 전환에서 제공업체의 역할
-전환 로직(예: BTC → USDT)은 거래소 파트너, 유동성 제공업체 또는 결제 제공업체의 자체 자금으로 처리될 수 있습니다. 가맹점은 변동성이나 유동성 위험으로부터 격리됩니다. 그들은 항상 USDT만 받습니다.
+전환 로직(예: BTC → USDT)은 거래소 파트너, 유동성 공급자 또는 결제 제공업체의 자체 자금으로 처리될 수 있습니다. 판매자는 변동성 또는 유동성 위험으로부터 보호됩니다. 판매자는 항상 USDT만 받습니다.
## 다음 권장 사항
-- [**USDT를 가스로 활용**](/ko/explanation/usdt-as-gas-token): USDT0가 Stable에서 기본 가스이자 ERC-20 잔액으로 어떻게 사용되는지 이해합니다.
-- [**USDT0를 Stable로 브리징**](/ko/explanation/usdt0-bridging): OFT Mesh 또는 Legacy Mesh를 통해 USDT0가 다른 체인에서 Stable로 어떻게 이동하는지 확인합니다.
+- [**USDT0를 가스로 사용**](/ko/explanation/usdt-as-gas-token): USDT0가 Stable에서 기본 가스 및 ERC-20 잔액으로 어떻게 사용되는지 이해합니다.
+- [**USDT0를 Stable로 브릿징**](/ko/explanation/usdt0-bridging): OFT Mesh 또는 Legacy Mesh를 통해 USDT0가 다른 체인에서 Stable로 어떻게 이동하는지 확인합니다.
- [**첫 USDT0 전송**](/ko/tutorial/send-usdt0): 표준 EVM 도구를 사용하여 테스트넷에서 USDT0 전송을 제출합니다.
diff --git a/docs/pages/ko/explanation/gas-pricing.mdx b/docs/pages/ko/explanation/gas-pricing.mdx
index 6f28761..8c9e250 100755
--- a/docs/pages/ko/explanation/gas-pricing.mdx
+++ b/docs/pages/ko/explanation/gas-pricing.mdx
@@ -1,42 +1,42 @@
---
source_path: explanation/gas-pricing.mdx
-source_sha: cee955370fcdfb739edadd48366ac6c984cbc9d9
+source_sha: 2f2ac159d9c7941aebcab3ae1fe43a666140e868
title: "가스 가격 책정"
-description: "Stable은 우선순위 팁이 없는 단일 구성 요소 가스 요금 모델을 사용하여 USDT0으로 표시되는 예측 가능한 비용을 제공합니다."
+description: "Stable은 우선순위 팁이 없는 단일 구성 요소의 가스 요금 모델을 사용하여 USDT0으로 표시되는 예측 가능한 비용을 제공합니다."
diataxis: "explanation"
---
# 가스 가격 책정
-Stable은 요금 변동성을 제거하고 예측 가능하며 낮은 트랜잭션 비용을 제공하도록 설계된 단순화된 단일 구성 요소 가스 요금 모델을 사용합니다. 트랜잭션 순서는 팁 입찰에 의해 영향을 받지 않습니다. 유효한 가스 가격은 프로토콜의 기본 요금에 의해서만 결정됩니다.
+Stable은 요금 변동성을 제거하고 예측 가능하며 낮은 트랜잭션 비용을 제공하도록 설계된 단순화된 단일 구성 요소 가스 요금 모델을 사용합니다. 트랜잭션 순서는 팁 입찰의 영향을 받지 않습니다. 유효한 가스 가격은 전적으로 프로토콜의 기본 수수료에 의해 결정됩니다.
## 이 모델을 사용하는 이유
-단일 구성 요소 설계에서 세 가지 속성이 파생됩니다.
+단일 구성 요소 설계에서 세 가지 속성이 나옵니다.
-- **예측 가능한 비용**: 수수료는 순전히 기본 실행 비용을 기반으로 합니다. 팁 경매는 분산을 도입하지 않습니다.
-- **USDT 표시 가격 책정**: 가스는 USDT0으로 가격이 책정되므로 달러 기준으로 비용을 추론하는 개발자 또는 사용자는 기본 토큰 가격 변동을 고려할 필요가 없습니다.
-- **극히 낮은 수수료**: 1 gwei의 기본 수수료로 기본 USDT0 전송(21,000 가스)은 약 **0.0000021 USDT0**이 듭니다. 복잡한 계약 상호 작용도 1센트 미만입니다.
+- **예측 가능한 비용**: 수수료는 순전히 기본 실행 비용을 기반으로 합니다. 팁 경매는 변동성을 유발하지 않습니다.
+- **USDT 표시 가격 책정**: 가스는 USDT0으로 가격이 책정되므로, 달러 기준으로 비용을 고려하는 개발자나 사용자는 기본 토큰 가격 변동을 고려할 필요가 없습니다.
+- **극히 낮은 수수료**: 1 gwei의 기본 수수료에서 기본 USDT0 전송(21,000 가스)은 대략 **0.0000021 USDT0**의 비용이 듭니다. 복잡한 계약 상호 작용도 1센트 미만입니다.
-## 이더리움과 비교
+## 이더리움과의 비교
| **매개변수** | **Stable** | **이더리움** |
| :--- | :--- | :--- |
| 가스 토큰 | USDT0 | ETH |
| 기본 수수료 | 예 | 예 |
-| 우선순위 팁 (`maxPriorityFeePerGas`) | 무시됨 (항상 0) | 주문에 사용됨 |
+| 우선순위 팁 (`maxPriorityFeePerGas`) | 무시됨 (항상 0) | 순서 지정에 사용됨 |
| EIP-1559 트랜잭션 형식 | 지원됨 | 지원됨 |
-Stable은 EIP-1559 (유형 2) 트랜잭션을 허용하지만, `maxPriorityFeePerGas`는 항상 무시됩니다. 트랜잭션 순서는 팁 입찰에 의해 영향을 받지 않습니다.
+Stable은 EIP-1559 (유형 2) 트랜잭션을 허용하지만 `maxPriorityFeePerGas`는 항상 무시됩니다. 트랜잭션 순서는 팁 입찰의 영향을 받지 않습니다.
-## 의미
+## 함의
-- **지갑**은 우선순위 팁 입력 필드를 숨기거나 비활성화해야 합니다. 값을 표시해도 효과가 없으므로 사용자를 혼란스럽게 할 수 있습니다.
-- **분석 대시보드**는 우선순위 수수료를 추적해서는 안 됩니다. 항상 0입니다.
-- **트랜잭션 구성 도구**는 `maxPriorityFeePerGas`를 명시적으로 `0`으로 설정한 다음, 최신 블록의 기본 수수료에서 안전 마진을 사용하여 `maxFeePerGas`를 계산해야 합니다.
+- **지갑**은 우선순위 팁 입력 필드를 숨기거나 비활성화해야 합니다. 표시하면 값이 효과가 없기 때문에 사용자에게 혼란을 줄 수 있습니다.
+- **분석 대시보드**는 우선순위 수수료를 추적해서는 안 됩니다. 항상 0이 됩니다.
+- **트랜잭션 구성 도구**는 `maxPriorityFeePerGas`를 명시적으로 `0`으로 설정한 다음, 최신 블록의 기본 수수료와 안전 여유를 사용하여 `maxFeePerGas`를 계산해야 합니다.
## 다음 권장 사항
-- [**가스 가격 책정 참조**](/ko/reference/gas-pricing-api): Stable의 요금 모델에 맞춰 트랜잭션을 구성하고, 가스를 추정하며, 도구를 구성합니다.
-- [**가스로서의 USDT**](/ko/explanation/usdt-as-gas-token): USDT0이 기본 가스와 ERC-20 잔액으로 어떻게 사용되는지 확인합니다.
-- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 포팅할 때 발생할 수 있는 모든 동작 차이를 검토합니다.
+- [**가스 가격 책정 참조**](/ko/reference/gas-pricing-api): Stable의 수수료 모델에 맞춰 트랜잭션을 구성하고, 가스를 추정하고, 도구를 구성합니다.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): USDT0이 기본 가스와 ERC-20 잔액으로 모두 사용되는 방법을 확인하십시오.
+- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 포팅할 때 발생할 모든 동작 차이점을 검토하십시오.
diff --git a/docs/pages/ko/explanation/gas-waiver.mdx b/docs/pages/ko/explanation/gas-waiver.mdx
index d2790c1..54b028f 100755
--- a/docs/pages/ko/explanation/gas-waiver.mdx
+++ b/docs/pages/ko/explanation/gas-waiver.mdx
@@ -1,61 +1,61 @@
---
source_path: explanation/gas-waiver.mdx
-source_sha: 7995b37c002721e3b84297b0e4c3ba54281c0d14
+source_sha: a03f510da6c1fe5ab2d31b55c8827b59792af6e0
title: "가스 면제"
-description: "가스 면제(Gas Waiver)를 통해 애플리케이션은 사용자를 위한 가스를 부담할 수 있습니다. 거버넌스 승인을 받은 면제는 서명된 페이로드를 가스 가격 0으로 실행하는 래퍼 트랜잭션을 제출합니다."
+description: "가스 면제를 통해 애플리케이션은 사용자의 가스를 부담할 수 있습니다. 거버넌스 승인을 받은 면제는 가스 가격이 0인 서명된 페이로드를 실행하는 래퍼 트랜잭션을 제출합니다."
diataxis: "explanation"
---
# 가스 면제
-거버넌스 승인을 받은 주소(이하 **면제자**)는 사용자의 서명된 페이로드를 담고 있는 래퍼 트랜잭션을 제출하며, 이를 `gasPrice = 0`으로 실행합니다. 사용자는 USDT0을 가지고 있지 않아도 되며 가스 비용을 지불하지 않습니다. Stable은 호스팅 서비스로 하나의 면제자를 운영하며, 파트너는 검증자 거버넌스를 통해 자체 면제자 주소를 등록할 수도 있습니다.
+거버넌스 승인을 받은 주소(이하 **면제 주소**)는 사용자가 서명한 페이로드를 포함하는 래퍼 트랜잭션을 `gasPrice = 0`으로 제출합니다. 사용자는 USDT0을 보유하지 않으며 가스를 지불하지 않습니다. Stable은 호스팅 서비스로 이러한 면제를 운영하며, 파트너는 검증자 거버넌스를 통해 자체 면제 주소를 등록할 수 있습니다.
## 동작 방식
-가스 면제는 래퍼 트랜잭션 패턴을 사용합니다:
+가스 면제는 래퍼 트랜잭션 패턴을 사용합니다.
-1. **사용자는 `gasPrice = 0`으로 `InnerTx`에 서명합니다.** 사용자의 서명은 처음부터 끝까지 보존됩니다. 면제자는 유효성을 손상시키지 않고 페이로드를 수정할 수 없습니다.
-2. **면제자는 `InnerTx`를 (`value = 0`, `gasPrice = 0`, 서명된 `InnerTx`를 데이터 페이로드로 하는) 프로토콜 마커 주소 (`0x000000000000000000000000000000000000f333`)로 전송되는 `WrapperTx`로 래핑합니다.**
-3. **검증자는 마커를 감지하여** 면제자의 권한 및 정책 제약을 확인하고, 사용자 신원(`from`, `nonce`, 호출 의미론)으로 내부 트랜잭션을 실행합니다.
+1. **사용자는 `gasPrice = 0`으로 `InnerTx`에 서명합니다.** 사용자의 서명은 처음부터 끝까지 보존되며, 면제자는 유효성을 손상시키지 않고 페이로드를 수정할 수 없습니다.
+2. **면제자는 `InnerTx`를 `WrapperTx`로 래핑합니다.** 이 `WrapperTx`는 프로토콜 마커 주소(`0x000000000000000000000000000000000000f333`)로 `value = 0`, `gasPrice = 0`, 그리고 서명된 `InnerTx`를 데이터 페이로드로 하여 전송됩니다.
+3. **검증자는 마커를 감지하고**, 면제자의 승인 및 정책 제약을 확인한 후, 사용자의 ID(`from`, `nonce`, 호출 의미론)로 내부 트랜잭션을 실행합니다.
-가스 회계는 면제 메커니즘 내에서 처리됩니다. 사용자는 아무것도 지불하지 않고, 래퍼도 아무것도 지불하지 않으며, 검증자는 면제자별 정책에 따라 비용을 흡수합니다.
+가스 회계 처리는 면제 메커니즘 내에서 처리됩니다. 사용자는 아무것도 지불하지 않으며, 래퍼도 아무것도 지불하지 않으며, 검증자는 면제별 정책에 따라 비용을 부담합니다.
-## 권한 부여 및 정책
+## 승인 및 정책
-면제자는 애플리케이션 로직이 아닌 검증자 거버넌스에 의해 제어됩니다. 거버넌스는 다음을 제공합니다:
+면제는 애플리케이션 로직이 아닌 검증자 거버넌스에 의해 제어됩니다. 거버넌스는 다음을 제공합니다.
-- **검토 가능한 등록**: 모든 면제자 주소는 온체인에 등록되며 상태에서 확인할 수 있습니다.
-- **철회**: 검증자는 오작동하는 면제자를 언제든지 제거할 수 있습니다.
-- **`AllowedTarget`을 통한 범위 지정 액세스**: 각 면제자는 특정 대상 계약 및 메서드 선택자 집합에 바인딩됩니다. 프로토콜은 내부 `to` 주소와 메서드 선택자가 해당 범위 밖에 있는 모든 래퍼를 거부합니다.
+- **검토 가능한 등록**: 모든 면제 주소는 온체인에 등록되어 상태에서 볼 수 있습니다.
+- **철회**: 검증자는 언제든지 오작동하는 면제를 제거할 수 있습니다.
+- **`AllowedTarget`을 통한 범위 지정 액세스**: 각 면제는 특정 대상 계약 및 메서드 선택자 집합에 바인딩됩니다. 프로토콜은 내부 `to` 주소와 메서드 선택자가 해당 범위를 벗어나는 래퍼를 거부합니다.
-유효한 래퍼 트랜잭션은 다음 모든 조건을 충족해야 합니다:
+유효한 래퍼 트랜잭션은 다음을 모두 만족해야 합니다.
- `WrapperTx.to == 0x000000000000000000000000000000000000f333` (마커 주소).
- `WrapperTx.from`은 거버넌스를 통해 온체인에 등록된 면제자입니다.
- `WrapperTx.gasPrice == 0` 및 `InnerTx.gasPrice == 0`.
- `WrapperTx.value == 0`.
-- `InnerTx.to`와 추출된 메서드 선택자는 면제자의 `AllowedTarget` 정책에 의해 허용됩니다.
+- `InnerTx.to` 및 추출된 메서드 선택자가 면제자의 `AllowedTarget` 정책에 의해 허용됩니다.
-어떤 조건이라도 실패하면, 검증자는 내부 트랜잭션을 실행하지 않고 래퍼를 거부합니다.
+어떤 조건이라도 실패하면 검증자는 내부 트랜잭션을 실행하지 않고 래퍼를 거부합니다.
## 보안 모델
-- **사용자 서명 무결성**: 사용자가 `InnerTx`에 서명합니다. 면제자는 서명의 유효성을 손상시키지 않고 페이로드를 변경할 수 없습니다. 파트너는 사용자가 의도한 페이로드에만 서명하도록 보장할 책임이 여전히 있습니다.
-- **온체인 권한 부여**: 권한 부여는 온체인에 있습니다. 요청이 어디에서 시작되었는지에 관계없이 거버넌스에 등록된 면제자 주소만 유효한 래퍼 제출을 생성할 수 있습니다.
-- **서비스 가용성 경계**: 파트너가 Stable의 호스팅된 면제 서버를 통해 라우팅할 때 제출 가용성은 서비스에 따라 달라집니다. 프로토콜 수준의 권한 부여 보장은 영향을 받지 않습니다.
+- **사용자 서명 무결성**: 사용자가 `InnerTx`에 서명합니다. 면제자는 서명 유효성을 손상시키지 않고 페이로드를 변경할 수 없습니다. 파트너는 여전히 사용자가 의도한 페이로드에만 서명하도록 보장할 책임이 있습니다.
+- **온체인 승인**: 승인은 온체인에 존재합니다. 요청의 출처에 관계없이 거버넌스에 등록된 면제 주소만 유효한 래퍼 제출을 생성할 수 있습니다.
+- **서비스 가용성 경계**: 파트너가 Stable의 호스팅된 면제 서버를 통해 라우팅할 때, 제출 가용성은 서비스에 따라 달라집니다. 프로토콜 수준의 승인 보장은 영향을 받지 않습니다.
## 가스 면제를 사용해야 하는 경우
-가스 면제는 최종 사용자가 가스를 위해 USDT0을 보유할 필요가 없는 모든 흐름에 적합합니다:
+가스 면제는 최종 사용자가 가스를 위해 USDT0을 보유할 필요가 없는 모든 흐름에 적합합니다.
- 아직 스테이블코인 잔액이 없는 사용자를 온보딩하는 소비자 앱.
-- 에이전트의 지갑이 가스를 지원하는 에이전트 주도 흐름.
-- 운영자가 네트워크 비용을 흡수하는 기업 결제 시스템.
+- 에이전트의 지갑이 가스를 조달하는 에이전트 주도 흐름.
+- 운영자가 네트워크 비용을 흡수하는 기업 결제 레일.
-사용자가 USDT0을 보유하고 있지만 여러 호출을 하나의 서명된 트랜잭션으로 묶고 싶어하는 흐름의 경우, 대신 [EIP-7702 위임](/ko/reference/eip-7702-api)을 참조하십시오.
+사용자가 USDT0을 보유하고 있지만 여러 호출을 하나의 서명된 트랜잭션으로 묶으려는 흐름의 경우, [EIP-7702 위임](/ko/reference/eip-7702-api)을 참조하세요.
## 다음 권장 사항
-- [**가스 없는 트랜잭션 활성화**](/ko/how-to/integrate-gas-waiver): API 키 제출 및 NDJSON 응답으로 호스팅된 면제 서버 API를 통합합니다.
+- [**가스 없는 트랜잭션 활성화**](/ko/how-to/integrate-gas-waiver): 호스팅된 면제 서버 API를 API 키 제출 및 NDJSON 응답과 통합합니다.
- [**가스 면제 프로토콜**](/ko/reference/gas-waiver-api): 마커 라우팅, 래퍼 형식, 거버넌스 제어 등 전체 프로토콜 사양을 읽어보세요.
-- [**가스 토큰으로서의 USDT**](/ko/explanation/usdt-as-gas-token): 면제가 적용되는 가스 토큰을 이해합니다.
+- [**USDT0을 가스로 사용**](/ko/explanation/usdt-as-gas-token): 면제가 적용되는 가스 토큰을 이해합니다.
diff --git a/docs/pages/ko/explanation/key-features.mdx b/docs/pages/ko/explanation/key-features.mdx
index e51d58c..e165166 100755
--- a/docs/pages/ko/explanation/key-features.mdx
+++ b/docs/pages/ko/explanation/key-features.mdx
@@ -1,36 +1,36 @@
---
source_path: explanation/key-features.mdx
-source_sha: 743dbe77cee418846f01652fecf871c2ab504539
+source_sha: 84c73f9671496f1f3dc766dd878111ef4d1b121a
title: '주요 기능'
-description: "Stable의 주요 사양(단일 슬롯 완결성, USDT0를 가스비로 사용, 완벽한 EVM 호환성)과 그 위에 구축된 USDT 특정 기능."
+description: "Stable의 주요 사양(단일 슬롯 완결성, USDT0를 가스로 사용, 완벽한 EVM 호환성)과 그 위에 구축된 USDT 특정 기능."
diataxis: "explanation"
---
# 주요 기능
-Stable은 단일 슬롯 완결성, 완전한 EVM 호환성, USDT0를 기본 가스 토큰으로 사용하는 DPoS(Delegated Proof-of-Stake) 레이어 1입니다. 아래 기능들은 일상적인 통합을 형성하는 기능들입니다. 각 기능은 해당 기능을 심층적으로 다루는 페이지로 연결됩니다.
+Stable은 단일 슬롯 완결성, 완벽한 EVM 호환성, USDT0를 기본 가스 토큰으로 사용하는 위임형 지분 증명 레이어 1입니다. 아래의 기능들은 일상적인 통합에 영향을 미치는 것들입니다. 각 링크는 해당 기능을 자세히 다루는 페이지로 연결됩니다.
## 프로토콜 수준 기능
| 기능 | 의미 |
| :--- | :--- |
-| **단일 슬롯 완결성** | 트랜잭션은 블록에 포함되면 최종 확정됩니다. 여러 블록 확인을 기다릴 필요가 없습니다. |
-| **완벽한 EVM 호환성** | Solidity, Vyper, Foundry, Hardhat, ethers, viem 및 `eth_*` RPC 메서드가 변경 없이 작동합니다. |
-| **USDT0를 가스비로 사용** | 하나의 자산이 기본 잔액과 ERC-20 역할을 모두 수행합니다. 별도의 가스 토큰을 보유할 필요가 없습니다. |
-| **크로스체인 브릿징** | USDT0는 LayerZero OFT를 통해 이더리움, Arbitrum, HyperEVM, Tron 및 기타 체인에서 Stable로 이동합니다. |
+| **단일 슬롯 완결성** | 트랜잭션은 블록에 포함되는 즉시 확정됩니다. 여러 블록 확인 대기가 없습니다. |
+| **완벽한 EVM 호환성** | Solidity, Vyper, Foundry, Hardhat, ethers, viem과 `eth_*` RPC 메서드가 변경 없이 작동합니다. |
+| **USDT0를 가스로 사용** | 하나의 자산이 기본 잔액과 ERC-20 역할을 모두 수행합니다. 별도의 가스 토큰을 보유할 필요가 없습니다. |
+| **교차 체인 브리징** | USDT0는 LayerZero OFT를 통해 이더리움, 아비트럼, HyperEVM, 트론 및 기타 체인에서 Stable로 이동합니다. |
## USDT 특정 기능
-- [**USDT를 가스비로 사용**](/ko/explanation/usdt-as-gas-token): USDT0는 동일한 잔액에서 기본 가스 토큰과 ERC-20 토큰의 역할을 모두 수행합니다.
-- [**가스비 면제**](/ko/explanation/gas-waiver): 거버넌스 승인 면제는 사용자 대신 0 가스 가격으로 실행되는 래퍼 트랜잭션을 제출합니다.
-- [**보장된 블록 공간**](/ko/explanation/guaranteed-blockspace): 엔터프라이즈 파트너는 결제 흐름을 위해 모든 블록에 예약된 용량을 확보합니다.
-- [**USDT 전송 애그리게이터**](/ko/explanation/usdt-transfer-aggregator): 대량의 USDT0 전송은 병렬화되고 내결함성이 있는 정산 번들로 일괄 처리됩니다.
-- [**기밀 전송**](/ko/explanation/confidential-transfer): 영지식 암호화는 전송 금액을 보호하면서 당사자가 감사받을 수 있도록 합니다.
+- [**USDT0를 가스로 사용**](/ko/explanation/usdt-as-gas-token): USDT0는 동일한 잔액에서 기본 가스 토큰과 ERC-20 토큰의 역할을 모두 수행합니다.
+- [**가스 면제**](/ko/explanation/gas-waiver): 거버넌스 승인 면제는 사용자를 대신하여 0 가스 가격으로 실행되는 래퍼 트랜잭션을 제출합니다.
+- [**보장된 블록스페이스**](/ko/explanation/guaranteed-blockspace): 엔터프라이즈 파트너는 모든 블록에서 결제 흐름에 대한 예약된 용량을 확보합니다.
+- [**USDT 전송 애그리게이터**](/ko/explanation/usdt-transfer-aggregator): 대량의 USDT0 전송은 병렬화되고 결함 허용적인 정산 번들로 일괄 처리됩니다.
+- [**기밀 전송**](/ko/explanation/confidential-transfer): 영지식 암호화는 전송 금액을 보호하면서 당사자들이 감사 가능하도록 유지합니다.
-어떤 업그레이드가 현재 적용되고 있고 어떤 업그레이드가 로드맵에 있는지 확인하려면 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요.
+현재 활성화된 업그레이드와 로드맵에 있는 업그레이드는 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요.
## 다음 권장 사항
-- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 Stable로 포팅할 때 어떤 점이 동일하게 유지되고 어떤 점이 변경되는지 확인합니다.
-- [**자금 흐름**](/ko/explanation/flow-of-funds): 온램프에서 온체인 전송을 거쳐 오프램프 정산까지 USDT의 경로를 추적합니다.
-- [**아키텍처 개요**](/ko/explanation/core-optimization-overview): 이러한 기능을 제공하는 합의, 실행, 데이터베이스 및 RPC 계층을 살펴봅니다.
+- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 Stable로 포팅할 때 무엇이 동일하고 무엇이 바뀌는지 확인하세요.
+- [**자금 흐름**](/ko/explanation/flow-of-funds): 온램프에서 온체인 전송, 오프램프 정산까지 USDT의 흐름을 추적하세요.
+- [**아키텍처 개요**](/ko/explanation/core-optimization-overview): 이러한 기능을 제공하는 합의, 실행, 데이터베이스 및 RPC 계층에 대해 알아보세요.
diff --git a/docs/pages/ko/explanation/learn-overview.mdx b/docs/pages/ko/explanation/learn-overview.mdx
index fd10cee..be9ba6c 100644
--- a/docs/pages/ko/explanation/learn-overview.mdx
+++ b/docs/pages/ko/explanation/learn-overview.mdx
@@ -1,37 +1,37 @@
---
source_path: explanation/learn-overview.mdx
-source_sha: a3bae707c2afb7477e50291b1b1311296a75a208
+source_sha: f8cb0e6ade6791dce2278fcf48cfe38d1d92c07c
title: "배우기"
-description: "Stable에 대한 개념, 아키텍처, 사용 사례 내러티브. Stable이 무엇인지, 이더리움과 어떻게 다른지, 그리고 USDT0를 가스로 사용하는 배경에 대한 정신적 모델."
+description: "Stable의 개념, 아키텍처, 사용 사례에 대한 설명입니다. Stable이 무엇인지, 이더리움과 어떻게 다른지, USDT0를 가스로 사용하는 이면의 정신적 모델을 다룹니다."
diataxis: "explanation"
---
# 배우기
-## 기초
+## 재단
-- [**개요**](/ko/explanation/overview): Stable이 무엇이며 이 문서를 읽는 방법.
-- [**주요 기능**](/ko/explanation/key-features): 주요 사양: 단일 슬롯 완결성, 가스로서의 USDT0, 완전한 EVM 호환성.
-- [**이더리움과의 차이점**](/ko/explanation/ethereum-comparison): 이더리움에서 포팅할 때 유지되는 것과 변경되는 것.
-- [**핵심 개념**](/ko/explanation/core-concepts): USDT0의 이중 역할, 보장된 블록 공간, 전송 통합자, 완결성.
+- [**개요**](/ko/explanation/overview): Stable이 무엇이며 이 문서를 읽는 방법입니다.
+- [**주요 기능**](/ko/explanation/key-features): 주요 사양: 단일 슬롯 완결성, USDT0를 가스로 사용, 완벽한 EVM 호환성.
+- [**이더리움과의 차이점**](/ko/explanation/ethereum-comparison): 이더리움에서 포팅할 때 변하지 않는 것과 변하는 것.
+- [**핵심 개념**](/ko/explanation/core-concepts): USDT0의 이중 역할, 보장된 블록 공간, 전송 애그리게이터, 완결성.
-USDT0 동작
+## USDT0 동작 방식
-- [**Stable에서의 USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 잔액, 조정 이벤트, 계약 설계 규칙.
-- [**가스로서의 USDT**](/ko/explanation/usdt-as-gas-token): Stable이 가스 비용 지불에 USDT0를 사용하는 이유와 이것이 수수료에 미치는 영향.
-- [**자금 흐름**](/ko/explanation/flow-of-funds): Stable에서 USDT가 엔드투엔드로 이동하는 방법.
-- [**USDT0 기능**](/ko/explanation/usdt-features-overview): 각 링크가 있는 모든 USDT0 특정 기능.
+- [**Stable에서의 USDT0 동작 방식**](/ko/explanation/usdt0-behavior): 이중 역할 잔액, 조정 이벤트, 계약 설계 규칙.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): Stable이 가스 비용 지불에 USDT0를 사용하는 이유와 이것이 수수료에 미치는 영향.
+- [**자금 흐름**](/ko/explanation/flow-of-funds): Stable에서 USDT가 종단 간에 이동하는 방식.
+- [**USDT0 기능**](/ko/explanation/usdt-features-overview): 각 기능에 대한 링크가 있는 모든 USDT0 관련 기능.
## 아키텍처
-- [**기술 개요**](/ko/explanation/tech-overview): 합의, 실행, 데이터베이스 및 RPC 계층을 한 페이지에.
+- [**기술 개요**](/ko/explanation/tech-overview): 합의, 실행, 데이터베이스, RPC 계층을 한 페이지에 담았습니다.
- [**핵심 최적화**](/ko/explanation/core-optimization-overview): 1초 미만 완결성 뒤에 숨겨진 성능 작업.
-- [**완결성**](/ko/explanation/finality): 단일 슬롯 완결성, 재구성 동작, "확인됨"의 의미.
-- [**가스 가격 책정**](/ko/explanation/gas-pricing): USDT0로 가격이 책정된 기본 수수료 전용 모델.
+- [**완결성**](/ko/explanation/finality): 단일 슬롯 완결성, 재구성 동작, "확정됨"의 의미.
+- [**가스 가격 책정**](/ko/explanation/gas-pricing): USDT0로 가격이 책정되는 기본 수수료 전용 모델.
-## 사용 사례 내러티브
+## 사용 사례 설명
-- [**결제**](/ko/explanation/use-case-payments): Stable이 P2P, 구독, 송장, 종량제에 적합한 이유.
+- [**결제**](/ko/explanation/use-case-payments): Stable이 P2P, 구독, 인보이스, 통화당 요금에 적합한 이유.
- [**급여**](/ko/explanation/use-case-payroll): Stable에서 일괄 및 예약된 급여 실행.
-- [**스폰서 트랜잭션**](/ko/explanation/use-case-sponsored): 애플리케이션이 사용자 가스 비용을 부담하게 하는 기능.
-- [**개인 전송**](/ko/explanation/use-case-private): 향후 기밀 결제 흐름.
+- [**후원 거래**](/ko/explanation/use-case-sponsored): 애플리케이션이 사용자 가스 비용을 부담할 수 있도록 합니다.
+- [**비공개 전송**](/ko/explanation/use-case-private): 예정된 기밀 결제 흐름.
diff --git a/docs/pages/ko/explanation/technical-roadmap.mdx b/docs/pages/ko/explanation/technical-roadmap.mdx
index 0ff497e..d8cd37c 100755
--- a/docs/pages/ko/explanation/technical-roadmap.mdx
+++ b/docs/pages/ko/explanation/technical-roadmap.mdx
@@ -1,14 +1,14 @@
---
source_path: explanation/technical-roadmap.mdx
-source_sha: e46692a227f4149b54598c9036a27e12659728ee
+source_sha: 12d6268b1d6e265ecdcb13be47d79ee8c3d0e443
title: "로드맵"
-description: "Stable의 단계별 최적화 로드맵: 현재 제공되는 기능, 다음 배송될 기능, 그 이후의 기능."
+description: "Stable의 단계별 최적화 로드맵: 현재 기능, 다음 출시될 기능, 그리고 그 이후의 계획."
diataxis: "explanation"
---
# 로드맵
-Stable은 세 단계를 거쳐 트랜잭션 파이프라인의 모든 계층(합의, 실행, 저장, RPC 및 USDT 특정 흐름)을 최적화합니다. 이 페이지에는 출시된 기능, 진행 중인 기능, 향후 예정된 기능이 표시됩니다.
+Stable은 거래 파이프라인의 모든 계층(합의, 실행, 저장소, RPC 및 USDT 특정 흐름)을 세 단계를 거쳐 최적화합니다. 이 페이지는 출시된 기능, 진행 중인 기능 및 향후 계획을 나타냅니다.
![기술 로드맵]()
-## 1단계: USDT를 위한 기반 레이어
+## 1단계: USDT를 위한 기본 계층
-상태: **메인넷 출시.**
+상태: **메인넷에 라이브.**
-### StableBFT: 출시 완료
+### StableBFT: 라이브
-CometBFT를 기반으로 구축된 맞춤형 PoS 합의 프로토콜입니다. 검증자의 1/3까지 결정론적 완결성과 비잔틴 장애 허용을 제공합니다. 현재 구현 사항은 [합의](/ko/explanation/consensus)를 참조하세요.
+CometBFT를 기반으로 구축된 맞춤형 PoS 합의 프로토콜입니다. 검증자의 1/3까지 결정론적 완결성과 비잔틴 장애 허용을 제공합니다. 현재 구현은 [합의](/ko/explanation/consensus)를 참조하십시오.
-### USDT를 기본 Gas로 사용: 출시 완료
+### USDT0을 기본 가스로: 라이브
-USDT0은 Gas 지불 및 가치 전송을 위한 기본 자산이며, 동시에 ERC-20 표면(`approve`, `transfer`, `transferFrom`, `permit`)을 지원합니다. [USDT를 Gas로 사용](/ko/explanation/usdt-as-gas-token)을 참조하세요.
+USDT0은 가스 지불 및 가치 이전을 위한 기본 자산이며, 동시에 ERC-20 표면(`approve`, `transfer`, `transferFrom`, `permit`)을 지원합니다. [가스 토큰으로서의 USDT0](/ko/explanation/usdt-as-gas-token)을 참조하십시오.
-### Stable Pay 및 Stable Name: 진행 중
+### Stable Pay & Stable Name: 진행 중
-Stable Pay는 기존 Web3 지갑과 호환되면서도 신규 사용자의 온보딩을 단순화하도록 설계된 Web2.5 UX 지갑 경험입니다. Stable Name은 원시 EVM 주소를 사람이 읽을 수 있는 식별자로 대체하여 토큰을 송수신하는 사용자 친화적인 별칭 시스템입니다.
+Stable Pay는 기존 Web3 지갑과의 호환성을 유지하면서 신규 사용자의 온보딩을 단순화하도록 설계된 Web2.5 UX 지갑 경험입니다. Stable Name은 원시 EVM 주소를 사람이 읽을 수 있는 식별자로 대체하여 토큰을 주고받을 수 있는 사용자 친화적인 별칭 시스템입니다.
-## 2단계: USDT를 위한 경험 레이어
+2단계: USDT를 위한 경험 계층
-상태: **Testnet에서 v1.4.0 릴리스 후보.** 메인넷 업그레이드 일정은 보류 중입니다. USDT Transfer Aggregator는 계속 개발 중입니다.
+상태: **테스트넷의 v1.4.0 릴리스 후보.** 메인넷 업그레이드 일정은 미정입니다. USDT 전송 애그리게이터는 개발 중입니다.
### MemIAVL 상태 저장소: v1.4.0에 포함
-MemIAVL은 LevelDB를 하나의 메모리 매핑 스냅샷과 추가 전용 쓰기 선행 로그로 대체합니다. RocksDB 기반 VersionDB는 보존된 스냅샷보다 오래된 기록 쿼리를 처리합니다. [저장소 (StableDB)](/ko/explanation/stable-db)를 참조하세요.
+MemIAVL은 LevelDB를 단일 메모리 매핑 스냅샷과 추가 전용 쓰기 선행 로그로 대체합니다. RocksDB 기반 VersionDB는 보존된 스냅샷보다 오래된 기록 쿼리를 처리합니다. [저장소 (StableDB)](/ko/explanation/stable-db)를 참조하십시오.
### 낙관적 병렬 실행: v1.4.0에 포함
-Block-STM은 CPU 코어 간에 트랜잭션을 동시에 실행하고, 충돌을 감지하며, 영향을 받는 작업을 재실행합니다. 고정된 블록 내 순서는 검증자 간에 결정론적 상태를 유지합니다. [실행](/ko/explanation/execution)을 참조하세요.
+Block-STM은 CPU 코어에서 트랜잭션을 동시에 실행하고, 충돌을 감지하고, 영향을 받는 작업을 재실행합니다. 고정된 블록 내 순서는 검증자 간에 결정론적 상태를 유지합니다. [실행](/ko/explanation/execution)을 참조하십시오.
### 선택적 RecheckTx: v1.4.0에 포함
-블록이 커밋되면 노드는 영향을 받는 계정의 보류 중인 트랜잭션만 재확인합니다. 애플리케이션 지원을 사용할 수 없는 경우 CometBFT는 전체 멤풀 재확인으로 폴백합니다.
+블록이 커밋된 후 노드는 영향을 받는 계정의 보류 중인 트랜잭션만 재확인합니다. 애플리케이션 지원이 제공되지 않는 경우 CometBFT는 전체 멤풀 재확인으로 폴백합니다.
### 2D 논스 및 보장된 블록 공간: v1.4.0에 포함
-독립적인 논스 채널은 하나의 막힌 트랜잭션이 동일한 계정의 모든 후속 트랜잭션을 차단하는 것을 방지합니다. 프로토콜 예약된 논스 키는 VIP 트래픽을 식별하는 반면, 레인별 Gas 할당량은 블록 용량을 예약합니다. [보장된 블록 공간](/ko/explanation/guaranteed-blockspace)을 참조하세요.
+독립적인 논스 채널은 하나의 막힌 트랜잭션이 동일한 계정의 모든 이후 트랜잭션을 차단하는 것을 방지합니다. 프로토콜 예약 논스 키는 VIP 트래픽을 식별하며, 레인별 가스 할당량은 블록 용량을 예약합니다. [보장된 블록 공간](/ko/explanation/guaranteed-blockspace)을 참조하십시오.
-### USDT Transfer Aggregator: 계획 중
+### USDT 전송 애그리게이터: 계획됨
-USDT0 전송을 그룹화하고 집합적으로 처리하여 트랜잭션당 오버헤드를 줄이고 전체 처리량을 개선하는 집계 메커니즘입니다. [USDT 전송 Aggregator](/ko/explanation/usdt-transfer-aggregator)를 참조하세요.
+USDT0 전송을 그룹화하고 집합적으로 처리하여 트랜잭션당 오버헤드를 줄이고 전체 처리량을 개선하는 집계 메커니즘입니다. [USDT 전송 애그리게이터](/ko/explanation/usdt-transfer-aggregator)를 참조하십시오.
-3단계: USDT를 위한 풀 스택 최적화 레이어
+## 3단계: USDT를 위한 풀스택 최적화 계층
-상태: **계획 중.**
+상태: **계획됨.**
### Autobahn의 StableBFT
-Stable의 CometBFT 기반 합의 계층과 자연스럽게 통합되는 DAG 기반 BFT 합의. 현재 프로토콜은 [StableBFT](/ko/explanation/consensus)를 참조하고, 목표 아키텍처는 [Autobahn](/ko/explanation/autobahn)을 참조하세요. 내부 POC(Proof-of-Concept)는 통제된
+Stable의 CometBFT 기반 합의 계층과 자연스럽게 통합되는 DAG 기반 BFT 합의입니다. 현재 프로토콜은 [StableBFT](/ko/explanation/consensus)를 참조하고, 목표 아키텍처는 [Autobahn](/ko/explanation/autobahn)을 참조하십시오. 내부 개념 증명은 통제된 환경에서 200,000 TPS 이상(합의만)을 시연했습니다.
+
+### StableVM++
+
+Go 기반 EVM을 C++ 구현으로 대체하는 고성능 실행 엔진입니다. EVM 실행 속도가 최대 6배 향상될 것으로 예상됩니다.
+
+### 고성능 RPC
+
+노드 수준 개선(실시간 체인 상태 처리), 노드 통합 인덱싱(저지연 애플리케이션 API), WebSocket을 통한 확장 가능한 pub/sub, 작업 유형에 따라 라우팅하는 하이브리드 로드 밸런서를 포함하는 완전한 RPC 스택입니다. 현재 분할 경로 아키텍처는 [고성능 RPC](/ko/explanation/high-performance-rpc)를 참조하십시오.
+
+## 다음 권장 사항
+
+- [**아키텍처 개요**](/ko/explanation/core-optimization-overview): 로드맵에 따라 진화하는 스택의 현재 상태를 살펴봅니다.
+- [**토크노믹스**](/ko/reference/tokenomics): 로드맵 전반에 걸쳐 검증자 인센티브에 자금을 지원하는 경제 모델을 검토합니다.
+- [**기술 개요**](/ko/explanation/tech-overview): 아키텍처 요약으로 돌아갑니다.
diff --git a/docs/pages/ko/explanation/usdt-as-gas-token.mdx b/docs/pages/ko/explanation/usdt-as-gas-token.mdx
index 3b1002b..4fe07e5 100755
--- a/docs/pages/ko/explanation/usdt-as-gas-token.mdx
+++ b/docs/pages/ko/explanation/usdt-as-gas-token.mdx
@@ -1,94 +1,94 @@
---
source_path: explanation/usdt-as-gas-token.mdx
-source_sha: 8097bf3fd47c99a316f073bd5a34afccef59988a
-title: 가스비로 쓰이는 USDT
-description: "USDT0가 어떻게 Stable의 네이티브 가스 토큰으로 기능하여 변동성 자산을 대체하고 예측 가능한 거래 수수료를 제공하는지 설명합니다."
+source_sha: 48402b67fa4dc4b93a575222ce0ea05b63646936
+title: 가스로서의 USDT0
+description: "변동성이 큰 자산을 대체하여 예측 가능한 트랜잭션 수수료를 위해 USDT0이 Stable의 기본 가스 토큰으로 기능하는 방법입니다."
diataxis: "explanation"
---
-# 가스비로 쓰이는 USDT
+# 가스로서의 USDT0
-**수수료는 USDT0으로 지불합니다. 두 번째 토큰, 래핑, ETH 상당액을 유지할 필요가 없습니다.** USDT0는 네이티브 가스 토큰이자 동일한 잔액의 ERC-20 토큰 역할을 합니다. 결제 수단으로 이동하는 동일한 자산이 해당 거래를 이동하는 데 필요한 수수료를 지불합니다. 수수료는 변동성이 큰 네이티브 토큰이 아닌 달러로 표시됩니다.
+**수수료는 USDT0으로 지불합니다. 두 번째 토큰, 래핑, 또는 ETH와 등가인 금액을 충전할 필요가 없습니다.** USDT0은 기본 가스 토큰이자 동일한 잔액의 ERC-20 토큰 역할을 합니다. 지불로 이동하는 자산 자체를 이동하는 트랜잭션의 비용을 지불합니다. 수수료는 변동성이 큰 기본 토큰이 아닌 달러로 표시됩니다.
-이러한 설계는 이더리움과는 다른 행동적 차이를 가지며, 이는 잔액 의미론, 허용 범위 안전성 및 특정 opcode 가정에 영향을 미칩니다. 이더리움에서 계약을 포팅하는 경우 배포 전에 마이그레이션 체크리스트는 [Stable의 USDT0 동작](/ko/explanation/usdt0-behavior)을 참조하십시오.
+이러한 설계는 이더리움과는 다른 동작 방식을 가지며, 잔액 의미, 허용 범위 안전성 및 특정 opcode 가정에 영향을 미칩니다. 이더리움에서 컨트랙트를 포팅하는 경우, 배포하기 전에 마이그레이션 체크리스트를 보려면 [Stable의 USDT0 동작](/ko/explanation/usdt0-behavior)을 참조하십시오.
-## 개요
+## 초록
-Stable은 USDT0를 네이티브 가스 토큰으로 사용하는 EVM 호환 블록체인입니다. USDT0는 가스 지불 및 가치 전송을 위한 네이티브 자산으로, 그리고 `approve`, `transfer`, `transferFrom`, `permit`을 지원하는 ERC-20 토큰으로 동시에 작동합니다.
+Stable은 USDT0을 기본 가스 토큰으로 사용하는 EVM 호환 블록체인입니다. USDT0은 가스 지불 및 가치 전송을 위한 기본 자산으로 동시에 기능하며, `approve`, `transfer`, `transferFrom`, `permit`을 지원하는 ERC-20 토큰으로도 작동합니다.
-이 문서는 Stable의 USDT0 가스 메커니즘을 명시하고, 그로 인한 행동 차이를 설명하며, Stable에 배포되는 스마트 계약에 필요한 권장 개발 패턴을 정의합니다.
+이 문서는 Stable의 USDT0 가스 메커니즘을 설명하고, 결과적인 동작 차이점을 기술하며, Stable에 배포된 스마트 컨트랙트에 대한 필수 및 권장 개발 패턴을 정의합니다.
-## 버전 참고
+## 버전 노트
-Stable v1.2.0부터 USDT0는 gUSDT를 대체하여 Stable의 네이티브 가스 토큰이 됩니다. 이 전환 과정의 일부로:
+Stable v1.2.0부터 USDT0은 gUSDT를 대체하여 Stable의 기본 가스 토큰이 됩니다. 이 전환의 일환으로:
-- gUSDT는 단계적으로 중단됩니다.
-- 기존 gUSDT 잔액은 USDT0로 자동 변환됩니다.
-- 사용자와 애플리케이션은 더 이상 수수료를 지불하거나 가치를 이동하기 위해 래핑 및 언래핑 흐름이 필요하지 않습니다.
+- gUSDT는 단계적으로 폐지됩니다.
+- 기존 gUSDT 잔액은 USDT0으로 자동 변환됩니다.
+- 사용자 및 애플리케이션은 더 이상 수수료를 지불하거나 가치를 이동하기 위해 래핑 및 언래핑 흐름이 필요하지 않습니다.
-v1.2.0 이후에는 USDT0가 다음과 같은 역할을 모두 수행합니다.
+v1.2.0 이후 USDT0은 다음 두 가지 역할을 합니다.
-- 네트워크 수수료 자산(gas), 그리고
-- `approve`, `permit`, `transfer`, `transferFrom`을 지원하는 표준 ERC20 토큰.
+- 네트워크 수수료 자산(가스)
+- `approve`, `permit`, `transfer`, `transferFrom`을 포함하는 표준 ERC20 토큰
## 네트워크 주소
-USDT0 토큰 계약 주소:
+USDT0 토큰 컨트랙트 주소:
- 테스트넷: [0x78cf24370174180738c5b8e352b6d14c83a6c9a9](https://testnet.stablescan.xyz/token/0x78cf24370174180738c5b8e352b6d14c83a6c9a9)
- 메인넷: [0x779ded0c9e1022225f8e0630b35a9b54be713736](https://stablescan.xyz/token/0x779ded0c9e1022225f8e0630b35a9b54be713736)
## 용어
-- **Stable**: USDT0가 네이티브 가스 토큰인 EVM 호환 블록체인.
-- **USDT0**: 다음 두 가지 기능을 모두 수행하는 LayerZero의 Omnichain Fungible Token(OFT) 표준을 사용하는 USDT의 옴니체인 버전:
- - 가스 및 가치 전송에 사용되는 네이티브 자산, 그리고
- - 허용 및 허가 의미론을 가진 ERC20 토큰.
-- **네이티브 잔액**: `address(x).balance`가 반환하는 USDT0 단위의 잔액.
-- **가스 수수료**: EIP-1559 스타일의 수수료 시장에서 계산되는 USDT0로 지불되는 거래 수수료.
+- **Stable**: USDT0이 기본 가스 토큰인 EVM 호환 블록체인.
+- **USDT0**: 다음 두 가지 역할을 하는 USDT의 옴니체인 버전:
+ - 가스 및 가치 전송에 사용되는 기본 자산
+ - 허용 및 허용 의미를 가진 ERC20 토큰
+- **기본 잔액**: `address(x).balance`로 반환되는 잔액으로, USDT0으로 표시됩니다.
+- **가스 수수료**: EIP-1559 스타일 수수료 시장에 따라 계산된 USDT0으로 지불되는 트랜잭션 수수료.
-## USDT0란?
+## USDT0이란 무엇인가요?
-USDT0는 LayerZero의 Omnichain Fungible Token (OFT) 표준을 사용하는 USDT의 옴니체인 표현입니다. USDT0는 USDT와 1:1로 고정되어 있으며 전통적인 브릿지 워크플로우나 래핑된 표현 없이 여러 블록체인 간에 이동하도록 설계되었습니다.
+USDT0은 LayerZero의 Omnichain Fungible Token (OFT) 표준을 사용하는 USDT의 옴니체인 표현입니다. USDT0은 USDT와 1:1로 고정되어 있으며, 기존 브리지 워크플로우나 래핑된 표현 없이 여러 블록체인에서 이동할 수 있도록 설계되었습니다.
-USDT0를 체인 간에 전송할 때, 토큰은 일부 소스 체인(해당 체인의 네이티브 USDT 지원에 따라 다름)에 잠기거나 소각됩니다. 그런 다음 LayerZero의 교차 체인 메시징을 통해 대상 체인에서 발행됩니다. 이는 유동성을 분할된 체인 로컬 풀이 아닌 단일 상호 운용 가능한 자산으로 통합하면서 1:1 고정 가치를 유지합니다.
+USDT0을 체인 간에 전송할 때, 토큰은 일부 소스 체인(해당 체인의 기본 USDT 지원에 따라 다름)에서 잠기거나 소각됩니다. 그런 다음 LayerZero의 교차 체인 메시징을 통해 대상 체인에 발행됩니다. 이렇게 하면 파편화된 체인 로컬 풀이 아닌 단일 상호 운용 가능한 자산으로 유동성을 통합하면서 1:1 고정을 유지할 수 있습니다.
-사용자에게는 더 빠른 온보딩, 운영 복잡성 감소 및 향상된 유동성 이동성을 제공합니다.
+사용자에게는 더 빠른 온보딩, 운영 복잡성 감소 및 유동성 이동성 향상을 가능하게 합니다.
## USDT0 및 Stable
-USDT0는 Stable의 온체인 경제 및 일상적인 사용을 지원하는 핵심 자산입니다. 동일한 자산이 수수료 지불 및 가치 전송에 모두 사용되므로 Stable은 다음 사항에 대한 마찰을 줄입니다.
+USDT0은 Stable의 온체인 경제학과 일상적인 사용을 지원하는 핵심 자산입니다. 동일한 자산이 수수료 지불과 가치 전송에 모두 사용되므로 Stable은 다음 경우에 마찰을 줄여줍니다.
-- **일반 사용자**: 더 간단한 온보딩 및 더 적은 토큰 개념
-- **개발자**: 더 간단한 수수료 및 가치 흐름
+- **일반 사용자**: 간편한 온보딩 및 더 적은 토큰 개념
+- **개발자**: 간편한 수수료 및 가치 흐름
- **기업**: 간소화된 회계 및 재무 운영
-Stable은 또한 LayerZero를 통해 다른 네트워크에서 USDT0를 온보딩할 수 있도록 함으로써 첫날부터 깊이 있는 USDT 유동성에 액세스할 수 있습니다.
+Stable은 또한 LayerZero를 통해 사용자가 다른 네트워크에서 USDT0을 온보딩할 수 있도록 함으로써 첫날부터 깊은 USDT 유동성에 접근할 수 있습니다.
## 가정 및 전제 조건
-아래 내용을 이해하려면 다음을 이해해야 합니다.
+아래 내용에 대해 다음 사항을 이해하고 있다고 가정합니다.
-- 솔리디티 실행 의미론 및 네이티브 값 전송
-- ERC20 허용 메커니즘 및 허가 흐름
-- Checks-Effects-Interactions를 포함한 표준 스마트 계약 보안 패턴
+- Solidity 실행 의미 및 기본 값 전송
+- ERC20 허용 메커니즘 및 허용 흐름
+- Checks-Effects-Interactions를 포함한 표준 스마트 컨트랙트 보안 패턴
## 1. 가스 및 수수료 모델
### 1.1 개요
-Stable은 모든 거래 수수료를 USDT0로 표시합니다. 가스 가격 책정은 동적으로 조정되는 기본 수수료와 함께 EIP-1559 스타일 모델을 따릅니다.
+Stable은 모든 트랜잭션 수수료를 USDT0으로 표시합니다. 가스 가격 책정은 동적으로 조정되는 기본 수수료와 함께 EIP-1559 스타일 모델을 따릅니다.
-거래 수수료는 다음과 같이 정의됩니다.
+트랜잭션 수수료는 다음과 같이 정의됩니다.
```text
fee = gasUsed × baseFee
```
-거래는 표준 EIP-1559 매개변수를 사용하여 `maxFeePerGas`를 지정할 수 있습니다.
+트랜잭션은 표준 EIP-1559 매개변수를 사용하여 `maxFeePerGas`를 지정할 수 있습니다.
-*참고: Stable은 우선 순위 팁을 지원하지 않습니다. `maxPriorityFeePerGas`를 설정하지 마십시오. 그렇지 않으면 팁 금액이 손실됩니다.*
+*참고: Stable은 우선순위 팁을 지원하지 않습니다. `maxPriorityFeePerGas`를 설정하지 마십시오. 그렇지 않으면 팁 금액이 손실됩니다.*
-### 1.2 거래 제출
+### 1.2 트랜잭션 제출
클라이언트는 최신 블록에서 최신 기본 수수료를 가져와 `maxFeePerGas`를 계산할 때 안전 마진을 포함해야 합니다.
@@ -104,36 +104,36 @@ const maxFeePerGas = baseFee * 2n + maxPriorityFeePerGas;
### 1.3 USDT0 획득
-계정은 다음을 통해 USDT0를 얻습니다.
+계정은 다음을 통해 USDT0을 얻습니다.
-- 다른 지원 체인에서 USDT0 브릿징
+- 다른 지원되는 체인에서 USDT0 브리징
- Stable의 다른 계정으로부터 전송 받기
-## 2. Stable이 USDT0를 가스 토큰으로 사용하는 방법
+## 2. Stable이 USDT0을 가스 토큰으로 사용하는 방법
-Stable은 선불 및 환불 정산 모델을 사용하여 USDT0로 가스를 청구합니다.
+Stable은 선불 및 환불 정산 모델을 사용하여 USDT0으로 가스를 청구합니다.
-### 거래 예시
+### 예시 트랜잭션
-Alice가 Bob에게 100 USDT0를 보냅니다.
+앨리스는 밥에게 100 USDT0을 보냅니다.
-### 2.1 사전 처리기 단계
+### 2.1 Ante-handler 단계
-`MonoEVMAnteHandler`에서 거래 유효성 검사 중:
+`MonoEVMAnteHandler`에서 트랜잭션 유효성 검사 중:
-1. Alice의 USDT0 잔액을 읽습니다.
-2. 프로토콜은 Alice가 다음을 충당할 수 있는지 확인합니다.
- - 거래 가치 (100 USDT0), 그리고
- - 최대 가능한 가스 수수료 (`gasWanted × fee`).
-3. 최대 가스 수수료가 선불로 이체됩니다.
- - `alice → fee_collector`로 USDT0 이체.
+1. 앨리스의 USDT0 잔액을 읽습니다.
+2. 프로토콜은 앨리스가 다음을 감당할 수 있는지 확인합니다.
+ - 트랜잭션 값 (100 USDT0)
+ - 가능한 최대 가스 수수료 (`gasWanted × fee`).
+3. 최대 가스 수수료는 선불로 이체됩니다.
+ - `alice → fee_collector`로 USDT0.
### 2.2 실행 단계
-`ApplyTransaction` 실행 중:
+`ApplyTransaction` 중:
-1. EVM이 트랜잭션을 실행합니다.
-2. 실제 가스 소모가 기록됩니다.
+1. EVM은 트랜잭션을 실행합니다.
+2. 실제 가스 소비량이 기록됩니다.
3. 값 전송이 적용됩니다.
- `alice → bob`으로 100 USDT0 전송.
@@ -141,29 +141,29 @@ Alice가 Bob에게 100 USDT0를 보냅니다.
실행 후:
-1. 프로토콜은 선불된 수수료의 미사용 부분을 계산합니다.
+1. 프로토콜은 선불 수수료 중 사용되지 않은 부분을 계산합니다.
```text
refund = (gasWanted − gasUsed) × baseFee
```
-2. 미사용 수수료는 환불됩니다.
- - `fee_collector → alice`로 USDT0 환불.
+2. 사용되지 않은 수수료는 환불됩니다.
+ - `fee_collector → alice`로 USDT0.
-## 3. 잔액 의미론 및 동작 차이
+## 3. 잔액 의미 및 동작 차이
-### 3.1 네이티브 잔액 변경 가능성
+### 3.1 기본 잔액 변경 가능성
-이더리움에서 계약의 네이티브 잔액은 일반적으로 계약 실행 결과로만 변경됩니다.
+이더리움에서 컨트랙트의 기본 잔액은 일반적으로 컨트랙트 실행의 결과로만 변경됩니다.
-Stable에서 계약의 네이티브 USDT0 잔액은 `transferFrom` 및 `permit`을 포함한 ERC20 허용 기반 작업으로 인해 변경될 수도 있습니다. 이러한 작업은 계약 코드를 호출하지 않고도 계약의 네이티브 잔액을 줄일 수 있습니다.
+Stable에서는 컨트랙트의 기본 USDT0 잔액이 `transferFrom` 및 `permit`을 포함한 ERC20 허용 기반 작업으로 인해 변경될 수도 있습니다. 이러한 작업은 컨트랙트 코드를 호출하지 않고도 컨트랙트의 기본 잔액을 줄일 수 있습니다.
-결과적으로, Stable에서는 다음 가정이 유효하지 않습니다.
-- 계약이 호출될 때만 계약의 네이티브 잔액이 줄어들 수 있습니다.
+결과적으로 다음 가정은 Stable에서 유효하지 않습니다.
+- 컨트랙트의 기본 잔액은 컨트랙트가 호출될 때만 감소할 수 있습니다.
-## 4. 계약 설계 요구사항
+## 4. 컨트랙트 설계 요구 사항
### 4.1 금지된 패턴: 미러링된 잔액 회계
-계약은 내부 변수에 의존하여 네이티브 잔액을 미러링해서는 안 됩니다.
+컨트랙트는 기본 잔액을 미러링하기 위해 내부 변수에 의존해서는 안 됩니다.
안전하지 않은 패턴의 예:
@@ -175,13 +175,13 @@ function deposit() external payable {
}
```
-이러한 변수는 허용 기반 전송을 통해 USDT0가 고갈되면 실제 네이티브 잔액과 달라질 수 있습니다.
+이러한 변수는 허용 기반 전송을 통해 USDT0이 소진되면 실제 기본 잔액과 다를 수 있습니다.
-### 4.2 필수 패턴: 실시간 잔액 지불 능력 확인
+### 4.2 필수 패턴: 실제 잔액 지불 능력 확인
-모든 네이티브 값 전송은 전송 직전에 `address(this).balance`를 사용하여 지불 능력(solvency)을 확인해야 합니다.
+모든 기본 값 전송은 전송 직전에 `address(this).balance`를 사용하여 지불 능력을 확인해야 합니다.
-예:
+예시:
```solidity
require(address(this).balance >= amount, "insufficient balance");
@@ -199,15 +199,15 @@ payable(msg.sender).call{value: amount}("");
### 4.3 상태 진행은 잔액 독립적이어야 합니다.
-진행, 이정표 또는 완료 조건에 의존하는 프로토콜 논리는 카운터 또는 에포크와 같은 비잔액 상태 변수를 사용하여 이를 명시적으로 추적해야 합니다.
+진행, 마일스톤 또는 완료 조건에 의존하는 프로토콜 로직은 카운터 또는 에포크와 같은 잔액과 무관한 상태 변수를 사용하여 명시적으로 추적해야 합니다.
-네이티브 잔액은 지불 시 지불 능력 확인에만 사용되어야 합니다.
+기본 잔액은 지급 시점에 지불 능력 확인을 위해서만 사용되어야 합니다.
### 4.4 허용 노출
-사용자 자금을 보관하는 계약은 외부 주소에 USDT0 허용권을 부여해서는 안 됩니다.
+사용자 자금을 보관하는 컨트랙트는 외부 주소에 USDT0 허용을 부여해서는 안 됩니다.
-허용이 불가피한 경우, 계약은 다음을 수행해야 합니다.
+허용이 불가피한 경우, 컨트랙트는 다음을 수행해야 합니다.
- 정확한 금액만 승인
- 사용 직후 허용 재설정
@@ -217,11 +217,11 @@ payable(msg.sender).call{value: amount}("");
### 5.1 EXTCODEHASH
-계약은 `EXTCODEHASH(addr) == 0x0`에 의존하여 주소가 사용된 적이 없다고 추론해서는 안 됩니다.
+컨트랙트는 주소가 사용된 적이 없다고 추론하기 위해 `EXTCODEHASH(addr) == 0x0`에 의존해서는 안 됩니다.
-주소 사용에 대한 모든 개념은 계약 상태 내에서 명시적으로 추적해야 합니다.
+주소 사용에 대한 모든 개념은 컨트랙트 상태 내에서 명시적으로 추적되어야 합니다.
-예:
+예시:
```solidity
mapping(address => bool) public used;
@@ -231,71 +231,71 @@ mapping(address => bool) public used;
Stable에서:
-- `address(0)`로의 네이티브 USDT0 전송은 되돌려집니다.
-- `address(0)`로의 ERC20 USDT0 전송도 되돌려집니다.
+- `address(0)`으로의 기본 USDT0 전송은 되돌려집니다.
+- `address(0)`으로의 ERC20 USDT0 전송도 되돌려집니다.
-제로 주소로 전송하여 USDT0를 소각하는 지원되는 메커니즘은 없습니다.
+제로 주소로 전송하여 USDT0을 소각하는 지원되는 메커니즘은 없습니다.
-계약은 다음을 수행해야 합니다.
+컨트랙트는 다음을 수행해야 합니다.
-- 수신자로 `address(0)`를 명시적으로 거부
-- 제로 주소 소각을 가정하는 모든 논리 재설계
-- 되돌릴 수 없는 손실 의미가 필요한 경우 명시적인 싱크 계약 사용
+- `address(0)`을 수신자로 명시적으로 거부
+- 제로 주소 소각을 가정하는 모든 로직 재설계
+- 돌이킬 수 없는 손실 의미가 필요한 경우 명시적 싱크 컨트랙트 사용
## 7. 테스트 요구 사항
Stable 배포를 위한 테스트 스위트는 다음을 포함해야 합니다.
-- 허용 기반 유출 시나리오(`approve` + `transferFrom`)
-- 실제 네이티브 잔액을 사용한 지불 능력 강제 적용
-- `EXTCODEHASH`에 의존하지 않는 주소 사용 논리
+- 허용 기반 소진 시나리오 (`approve` + `transferFrom`)
+- 실제 기본 잔액을 사용한 지불 능력 시행
+- `EXTCODEHASH`에 의존하지 않는 주소 사용 로직
- 제로 주소 전송에 대한 명시적 실패 사례
## 8. 마이그레이션 체크리스트
-이더리움에서 Stable로 계약을 포팅할 때:
+이더리움에서 Stable로 컨트랙트를 포팅할 때:
-- 내부 네이티브 잔액 미러 제거
-- 모든 지불 능력 확인을 `address(this).balance`로 교체
-- `address(0)`로의 모든 네이티브 또는 ERC20 전송 제거
+- 내부 기본 잔액 미러 제거
+- 모든 지불 능력 확인을 `address(this).balance`로 대체
+- `address(0)`으로의 모든 기본 또는 ERC20 전송 제거
- 모든 USDT0 승인 감사
-- 허가 및 허용 기반 흐름을 다루는 테스트 추가
+- 허용 및 허용 기반 흐름을 다루는 테스트 추가
## 9. 요약
-Stable의 USDT0 가스 토큰 사용은 예측 가능한 수수료와 통합된 가치 회계를 제공하는 동시에 네이티브 잔액 동작에 대한 핵심 가정을 변경합니다.
+USDT0을 가스 토큰으로 사용하는 Stable은 예측 가능한 수수료와 통합된 가치 회계를 제공하는 동시에 기본 잔액 동작에 대한 핵심 가정을 변경합니다.
-Stable에서 올바른 계약 설계는 다음을 필요합니다.
+Stable에서 올바른 컨트랙트 설계는 다음을 요구합니다.
-- USDT0를 이중 역할 자산으로 취급
-- 실제 잔액에 대한 지불 능력 강제 적용
-- 허용 기반 유출 경로 회피
+- USDT0을 이중 역할 자산으로 처리
+- 실제 잔액에 대한 지불 능력 시행
+- 허용 기반 유출 경로 방지
- 이더리움 특정 잔액 및 주소 가정에 대한 의존성 제거
## FAQ
-**현재 USDT0를 래핑된 네이티브 토큰으로 사용하고 있습니다. 이 업그레이드 후에 어떤 토큰을 래핑된 네이티브 토큰으로 간주해야 합니까?**
+### 통합에서 래핑된 기본 토큰으로 어떤 토큰을 처리해야 합니까?
-업그레이드 후 USDT0는 네이티브 토큰이자 ERC-20 토큰이 됩니다. USDT0를 직접 사용해야 하며, 래핑 또는 언래핑은 더 이상 필요하지 않습니다.
+업그레이드 후 USDT0은 기본 토큰이자 ERC-20 토큰이 됩니다. USDT0을 직접 사용하십시오. 더 이상 래핑하거나 언래핑할 필요가 없습니다.
-**원래 USDT0 계약 주소(`0x779Ded0c9e1022225f8E0630b35a9b54bE713736`)는 어떻게 됩니까?**
+### 원래 USDT0 컨트랙트 주소는 어떻게 됩니까?
-아무것도 변경되지 않습니다. 동일한 주소가 계속 유효하며 USDT0를 나타냅니다.
+아무것도 변하지 않습니다. `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`은 유효하며 계속해서 USDT0을 나타냅니다.
-**업그레이드 후 네이티브 토큰 주소가 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`입니까 ( `0x0000000000000000000000000000000000001000` 대신)?**
+### 기본 토큰을 식별하는 주소는 무엇입니까?
-예. 업그레이드 후 네이티브 토큰 식별자/주소는 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`입니다.
+기본 토큰 식별자는 `0x0000000000000000000000000000000000001000`이 아닌 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`입니다.
-**`0x0000000000000000000000000000000000001000`는 어떻게 됩니까? gUSDT의 토큰 주소로 여전히 사용됩니까? 그리고 우리 측에서 이를 유지해야 합니까?**
+### 통합은 이전 gUSDT 주소를 유지해야 합니까?
-아니요. 제거할 수 있습니다. 업그레이드 후에는 사용되지 않습니다.
+아니요. `0x0000000000000000000000000000000000001000`을 제거할 수 있습니다. 업그레이드 후에는 사용되지 않습니다.
-**DEX 캘데이터의 경우, 프로토콜은 "네이티브 토큰" 식별자로 `0x0000000000000000000000000000000000001000` 대신 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`를 사용하지 않게 됩니까?**
+### DEX calldata는 어떤 기본 토큰 식별자를 사용해야 합니까?
-맞습니다. 업그레이드 후 DEX는 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`를 네이티브 토큰 식별자로 사용해야 합니다.
+DEX calldata는 기본 토큰 식별자로 `0x779Ded0c9e1022225f8E0630b35a9b54bE713736`을 사용해야 합니다.
## 다음 권장 사항
-- [**첫 USDT0 전송하기**](/ko/tutorial/send-usdt0): 표준 EVM 도구를 사용하여 테스트넷에서 USDT0 전송을 제출하세요.
-- [**가스 가격 책정**](/ko/reference/gas-pricing-api): Stable의 단일 구성 요소 수수료 모델에 대해 트랜잭션을 구축하세요.
-- [**Stable에서 USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 자산 의미론, 잔액 조정 및 `EXTCODEHASH` 동작에 대해 계약을 감사하세요.
+- [**첫 번째 USDT0 전송하기**](/ko/tutorial/send-usdt0): 표준 EVM 도구를 사용하여 테스트넷에서 USDT0 전송을 제출하세요.
+- [**가스 가격 책정**](/ko/reference/gas-pricing-api): Stable의 단일 구성 요소 수수료 모델에 따라 트랜잭션을 구축하세요.
+- [**Stable의 USDT0 동작**](/ko/explanation/usdt0-behavior): 이중 역할 자산 의미, 잔액 조정 및 `EXTCODEHASH` 동작에 대해 컨트랙트를 감사하세요.
diff --git a/docs/pages/ko/explanation/usdt-features-overview.mdx b/docs/pages/ko/explanation/usdt-features-overview.mdx
index eff30e0..aabdad9 100755
--- a/docs/pages/ko/explanation/usdt-features-overview.mdx
+++ b/docs/pages/ko/explanation/usdt-features-overview.mdx
@@ -1,43 +1,43 @@
---
source_path: explanation/usdt-features-overview.mdx
-source_sha: 57d3ff5eccb576fb54ee22d218ee257c2e845bff
+source_sha: c60f456a8e4e135e4a648496f7628719b8f18d23
title: "개요"
-description: "Stable의 다섯 가지 USDT별 기능이 어떻게 함께 작동하여 스테이블코인 결제 흐름을 대규모로 실용적으로 만드는지 설명합니다."
+description: "Stable의 USDT 특정 기능 5가지가 어떻게 함께 작동하여 스테이블코인 결제 흐름을 대규모로 실용화하는지 설명합니다."
diataxis: "explanation"
---
# 개요
-Stable의 USDT별 기능은 독립적인 옵션 메뉴가 아닙니다. 이들은 서로 구성됩니다. 각 기능은 스테이블코인 결제가 데모에서 프로덕션으로 전환될 때 발생하는 특정 마찰을 제거합니다. 이 페이지에서는 다섯 가지 기능이 함께 존재하는 이유를 설명합니다.
+Stable의 USDT 특정 기능들은 독립적인 옵션 메뉴가 아닙니다. 이들은 서로 구성되어 있습니다. 각 기능은 스테이블코인 결제가 데모 단계를 넘어 프로덕션으로 전환될 때 나타나는 특정 마찰 요소를 제거합니다. 이 페이지에서는 이 다섯 가지 기능들이 왜 함께 존재해야 하는지 설명합니다.
## 마찰 스택
-범용 체인의 대부분의 스테이블코인 결제 아키텍처는 동일한 문제 스택에 직면합니다.
+대부분의 범용 체인에서 스테이블코인 결제 아키텍처는 동일한 문제 스택에 직면합니다.
-1. **사용자는 스테이블코인을 이동하는 트랜잭션의 가스 비용을 지불하기 위해 두 번째 토큰(ETH, SOL)을 보유해야 합니다.** 전환율을 저하시키는 온보딩 단계입니다.
-2. **두 번째 토큰이 있더라도 사용자는 가스 비용을 부담해야 합니다.** 이는 상인과 결제 앱이 필요로 하는 "1달러에 1달러 송금"이라는 정신적 모델을 깨뜨립니다.
-3. **네트워크 활동에 따라 거래 비용이 변동됩니다.** 급여, 재무 운영 및 일괄 결제는 비용 또는 포함을 계획할 수 없습니다.
-4. **거래당 제한은 처리량을 제한합니다.** 대량 USDT 흐름은 체인 전체의 경합에 부딪히고 관련 없는 활동과 함께 저하됩니다.
-5. **모든 거래는 공개적으로 관찰 가능합니다.** 공급자 지급, 급여 실행 및 재무 이동은 상업적으로 민감한 데이터를 유출합니다.
+1. **사용자는 두 번째 토큰을 보유해야 합니다.** (ETH, SOL) 스테이블코인을 이동시키는 거래에 대한 가스비를 지불하기 위해서입니다. 온보딩 단계에서 전환율이 떨어집니다.
+2. **두 번째 토큰이 있더라도 사용자가 가스비를 부담해야 합니다.** 이는 상인 및 결제 앱이 필요로 하는 "1달러를 보내면 1달러"라는 정신 모델을 깨뜨립니다.
+3. **네트워크 활동에 따라 거래 비용이 변동됩니다.** 급여, 재무 운영, 배치 정산 등은 비용이나 포함 여부를 계획할 수 없습니다.
+4. **거래당 제한은 처리량을 제한합니다.** 고량의 USDT 흐름은 체인 전체의 경쟁을 유발하고 관련 없는 활동과 함께 성능이 저하됩니다.
+5. **모든 거래는 공개적으로 관찰 가능합니다.** 공급자 결제, 급여 지급, 재무 이동은 상업적으로 민감한 데이터를 누출합니다.
-## 기능 구성 방법
+## 기능 구성 방식
-Stable은 전용 메커니즘으로 각 마찰을 해결합니다.
+Stable은 전용 메커니즘으로 각 마찰 요소를 해결합니다.
-| 마찰 | 메커니즘 | 페이지 |
+| 마찰 요소 | 메커니즘 | 페이지 |
| :--- | :--- | :--- |
-| 별도의 가스 토큰 | USDT0는 기본 가스 토큰입니다 | [가스 토큰으로서의 USDT](/ko/explanation/usdt-as-gas-token) |
-| 사용자가 가스를 전혀 지불하지 않음 | 거버넌스 승인 면제가 가스 비용을 부담합니다 | [가스 면제](/ko/explanation/gas-waiver) |
-| 비용 및 포함 변동성 | 등록된 파트너를 위한 예약된 블록 용량 | [보장된 블록 공간](/ko/explanation/guaranteed-blockspace) |
-| 처리량 상한선 | 병렬화된 USDT0 전송 일괄 처리 | [USDT 전송 Aggregator](/ko/explanation/usdt-transfer-aggregator) |
-| 공용 금액 가시성 | ZK 암호화를 통한 선택적 프라이버시 | [기밀 전송](/ko/explanation/confidential-transfer) |
+| 별도의 가스 토큰 | USDT0은 기본 가스 토큰입니다 | [가스용 USDT0](/ko/explanation/usdt-as-gas-token) |
+| 사용자가 가스비를 지불해야 함 | 거버넌스 승인 면제가 가스비를 충당합니다 | [가스 면제](/ko/explanation/gas-waiver) |
+| 비용 및 포함 편차 | 등록된 파트너를 위한 예약된 블록 용량 | [보장된 블록 공간](/ko/explanation/guaranteed-blockspace) |
+| 처리량 상한선 | 병렬 USDT0 전송 일괄 처리 | [USDT 전송 통합자](/ko/explanation/usdt-transfer-aggregator) |
+| 공개 금액 가시성 | ZK 암호화를 통한 선택적 개인 정보 보호 | [기밀 전송](/ko/explanation/confidential-transfer) |
-이들 중 하나라도 도움이 됩니다. 이들을 함께 사용하면 Stable은 결제 팀이 기존 카드 네트워크에서와 동일한 방식으로 비용, 지연 시간 및 개인 정보를 모델링할 수 있는 체인이 되며, 블록체인의 결제 완결성을 제공합니다.
+이들 중 어느 하나도 도움이 되지만, 함께 사용하면 Stable은 결제 팀이 전통적인 카드 네트워크에서와 동일한 방식으로 비용, 지연 시간 및 개인 정보 보호를 모델링할 수 있는 체인이 됩니다. 물론 블록체인의 최종 정산 기능도 함께 제공됩니다.
-범용 EVM 체인과 Stable의 전체 차이점에 대해서는 [이더리움 비교](/ko/explanation/ethereum-comparison)를 참조하십시오. 이러한 기능을 통해 USDT가 처음부터 끝까지 이동되는 작업 예시는 [자금 흐름](/ko/explanation/flow-of-funds)을 참조하십시오.
+범용 EVM 체인과 Stable의 모든 차이점에 대해서는 [이더리움 비교](/ko/explanation/ethereum-comparison)를 참조하십시오. 이러한 기능을 통해 USDT가 어떻게 처음부터 끝까지 이동하는지에 대한 작동 예시는 [자금 흐름](/ko/explanation/flow-of-funds)을 참조하십시오.
## 다음 권장 사항
-- [**가스 토큰으로서의 USDT**](/ko/explanation/usdt-as-gas-token): 가스 및 결제를 동시에 대체하는 자산을 이해하십시오.
-- [**자금 흐름**](/ko/explanation/flow-of-funds): 온램프에서 온체인 전송을 거쳐 오프램프 결제까지 USDT의 경로를 추적하십시오.
-- [**USDT0를 Stable 브리징**](/ko/explanation/usdt0-bridging): 다른 체인에서 Stable로 USDT0가 이동하는 방법을 알아보십시오.
+- [**가스용 USDT0**](/ko/explanation/usdt-as-gas-token): 이더리움을 대체하여 가스와 결제를 동시에 처리하는 자산을 이해합니다.
+- [**자금 흐름**](/ko/explanation/flow-of-funds): 온램프에서 온체인 전송, 오프램프 정산까지 USDT를 추적합니다.
+- [**USDT0를 Stable 블록체인으로 브리징하기**](/ko/explanation/usdt0-bridging): USDT0가 다른 체인에서 Stable로 이동하는 방법을 확인합니다.
diff --git a/docs/pages/ko/explanation/usdt-transfer-aggregator.mdx b/docs/pages/ko/explanation/usdt-transfer-aggregator.mdx
index 255f66d..c4b0411 100755
--- a/docs/pages/ko/explanation/usdt-transfer-aggregator.mdx
+++ b/docs/pages/ko/explanation/usdt-transfer-aggregator.mdx
@@ -1,84 +1,84 @@
---
source_path: explanation/usdt-transfer-aggregator.mdx
-source_sha: 23229418f878c0594cd6e8e891e188b95df6c4ec
-title: "USDT 전송 애그리게이터"
-description: "USDT 전송 애그리게이터는 고용량 USDT0 전송을 병렬화되고 내결함성을 가진 결제로 일괄 처리합니다."
+source_sha: 65a8d11eab81088117f6db9c762a3c9bc95cdea4
+title: "USDT 이체 어그리게이터"
+description: "USDT 이체 어그리게이터는 대량의 USDT0 이체를 병렬화되고 오류 허용 범위가 높은 결제로 일괄 처리합니다."
diataxis: "explanation"
---
-# USDT 전송 애그리게이터
+# USDT 이체 어그리게이터
-**USDT 전송 애그리게이터**는 각 전송을 순차적으로 처리하는 대신 USDT0 전송을 병렬화되고 내결함성을 가진 배치로 묶습니다. 이를 통해 USDT0 처리량을 나머지 실행 파이프라인과 분리하여 고용량 스테이블코인 활동이 다른 트랜잭션을 방해하지 않도록 합니다.
+**USDT 이체 어그리게이터**는 각각의 이체를 순차적으로 처리하는 대신 USDT0 이체를 병렬화되고 오류 허용 범위가 높은 배치로 묶습니다. 이는 USDT0 처리량을 나머지 실행 파이프라인과 분리하여 대량 스테이블코인 활동이 다른 트랜잭션을 압도하지 않도록 합니다.
:::note
-**계획 중.** 애그리게이터는 장기적인 로드맵 항목입니다. 아래 내용은 목표 설계를 설명합니다. 시기N에 대한 정보는 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요.
+**계획 중.** 어그리게이터는 미래 지향적인 로드맵 항목입니다. 아래 내용은 목표 설계를 설명합니다. 시기에 대해서는 [로드맵](/ko/explanation/technical-roadmap)을 참조하세요.
:::
-## 존재하는 이유
+## 존재 이유
-두 가지 제약 사항이 서로 충돌합니다.
+두 가지 제약이 서로 상충합니다.
-- 기존 ERC-20 전송은 순차적으로 처리됩니다. 높은 부하에서는 병목 현상이 발생합니다.
-- 단순히 USDT0에 우선순위를 부여하면 다른 트랜잭션을 방해하고 전체 체인 성능을 저하시킬 수 있습니다.
+- 기존 ERC-20 이체는 순차적으로 처리됩니다. 부하가 높으면 병목 현상이 발생합니다.
+- 단순히 USDT0에 우선순위를 부여하면 다른 트랜잭션을 압도하고 일반 체인 성능을 저하시킬 수 있습니다.
-애그리게이터는 USDT0 전송을 전용 병렬 파이프라인으로 가져와서 다른 모든 작업에 대한 메인 실행 경로를 그대로 두는 방식으로 이를 해결합니다.
+어그리게이터는 USDT0 이체를 전용 병렬 파이프라인으로 끌어들여 이 문제를 해결하고, 메인 실행 경로는 다른 모든 것을 위해 그대로 둡니다.
## 병렬 집계 및 검증
-전송 집계 시스템의 핵심에는 `MapReduce` 계산 모델에서 영감을 받은 병렬화 가능한 집계 및 검증 파이프라인이 있습니다. 시스템은 각 전송을 순서대로 처리하는 대신, 균형 업데이트를 실행하기 전에 계정 간에 입력 및 출력을 집계하는 번들 수준 계산을 수행합니다.
+이체 집계 시스템의 핵심은 `MapReduce` 계산 모델에서 영감을 받은 병렬화 가능한 집계 및 검증 파이프라인입니다. 각 이체를 순서대로 처리하는 대신, 시스템은 잔액 업데이트를 실행하기 전에 계정 간에 입력 및 출력을 집계하는 번들 수준 계산을 수행합니다.
### 주요 단계
-1. **계정 차이 집계**
- - 각 전송은 발신자와 수신자에 매핑됩니다.
- - 각 계정에 대해 순 토큰 이동을 나타내는 차이 저널이 생성됩니다.
- - 총 차변(송금)에 대한 음수 값.
- - 총 대변(수신)에 대한 양수 값.
-2. **잔액 확인**
- - 시스템은 총 입력이 총 출력과 같다는 전역 잔액 불변성을 보장합니다.
- - 충분한 자금을 확인하기 위해 각 계정의 순 변경 사항은 병렬로 독립적으로 검증됩니다.
- - 잔액이 부족한 계정은 번들을 중단하지 않고 플래그가 지정됩니다.
-3. **병렬 처리를 위한 MapReduce 모델**
- - **맵 단계**: 모든 들어오고 나가는 전송을 기반으로 각 계정의 순 델타를 계산합니다.
- - **감소 단계**: 최종 상태 업데이트를 결정하기 위해 이러한 델타를 집계합니다.
+1. **계정 차이 집계**
+ - 각 이체는 발신자와 수신자에게 매핑됩니다.
+ - 정미 토큰 이동을 나타내는 각 계정에 대한 차이 일지가 생성됩니다.
+ - 총 차변(보내기)에 대한 음수 값.
+ - 총 대변(받기)에 대한 양수 값.
+2. **잔액 확인**
+ - 시스템은 전역 잔액 불변성을 보장합니다. 총 입력은 총 출력과 같습니다.
+ - 각 계정의 순 변경은 충분한 자금을 확인하기 위해 병렬로 독립적으로 검증됩니다.
+ - 잔액이 불충분한 계정은 번들을 중단하지 않고 플래그가 지정됩니다.
+3. **병렬 처리를 위한 MapReduce 모델**
+ - **맵 단계**: 모든 수신/발신 이체를 기반으로 각 계정에 대한 순 델타를 계산합니다.
+ - **축소 단계**: 이러한 델타를 집계하여 최종 상태 업데이트를 결정합니다.
## 기술적 특징
### 병렬 계산 모델
-- 선 컴파일된 계약에서 병렬 처리를 활용하여 잔액을 확인하고 차이를 동시에 계산합니다.
-- 기존의 순차적인 ERC20 처리와 비교하여 실행 시간을 크게 단축합니다.
+- 사전 컴파일된 계약에서 병렬 처리를 활용하여 잔액을 확인하고 차이를 동시에 계산합니다.
+- 기존의 순차적 ERC20 처리와 비교하여 실행 시간을 크게 단축합니다.
### 종속성 분석
-- 중복 전송(예: 동일한 계정에서 여러 번 전송)을 식별합니다.
-- 계단식 오류를 최소화하기 위해 위험이 높은 전송(예: 자금 부족 가능성)을 미리 플래그 지정합니다.
+- 중복 이체(예: 동일한 계정에서 여러 번 보내기)를 식별합니다.
+- 연쇄적인 실패를 최소화하기 위해 고위험 이체(예: 자금 부족 가능성)에 미리 플래그를 지정합니다.
### 모듈형 오류 처리
-- 전송은 계정 수준에서 격리되므로 문제 있는 계정만 영향을 받습니다.
-- 충돌하지 않는 전송은 정상적으로 실행되고 완료됩니다.
+- 이체는 계정 수준에서 격리되므로 문제가 있는 계정만 영향을 받습니다.
+- 충돌하지 않는 이체는 정상적으로 실행되고 완료됩니다.
### 선택적 오류 처리
-기존의 전송 처리는 블록 내에서 전체 또는 없음입니다. Stable의 집계 모델은 세분화된 계정별 오류 격리를 도입합니다.
+기존 이체 처리는 블록 내에서 모두 아니면 아무것도 아닙니다. Stable의 집계 모델은 세분화된 계정별 오류 격리를 도입합니다.
-- 계정의 `현재 잔액 + 순 차이 < 0`인 경우, 시스템은 해당 계정의 전송만 실패로 표시합니다.
-- 다른 계정을 포함하는 전송은 정상적으로 진행됩니다.
-- 이 선택적 롤백 메커니즘은 유효하지 않거나 악의적인 전송이 전체 번들의 무결성을 손상시키지 않도록 합니다.
+- 계정의 `현재 잔액 + 순 차이 < 0`인 경우 시스템은 해당 계정의 이체만 실패로 표시합니다.
+- 다른 계정과 관련된 이체는 정상적으로 진행됩니다.
+- 이 선택적 롤백 메커니즘은 유효하지 않거나 악의적인 이체가 전체 번들의 무결성을 손상시키지 않도록 합니다.
-## 제안자 주도 또는 평판 기반 정렬
+## 제안자 기반 또는 평판 기반 정렬
-실행을 더욱 최적화하고 상태 충돌을 방지하기 위해 Stable은 집계된 전송에 대한 전처리 정렬 메커니즘을 통합합니다.
+실행을 더욱 최적화하고 상태 충돌을 방지하기 위해 Stable은 집계된 이체에 대한 전처리 순서 지정 메커니즘을 통합합니다.
-- **평판 기반 정렬**: 강력한 기록 또는 입증된 신뢰성을 가진 발신자는 우선 순위가 지정되어 실패 및 재정렬의 위험을 줄입니다.
-- **제안자 기반 순서**: 트랜잭션은 충돌을 최소화하고 처리량을 최대화하도록 번들을 구성하는 신뢰할 수 있는 제안자 노드에 의해 정렬될 수 있습니다.
-- **번들 전송 우선 순위 지정**: 집계된 USDT 전송은 일반 트랜잭션보다 우선 순위가 지정되어 종속성 충돌을 줄이고 더 깨끗한 실행 창을 확보합니다.
+- **평판 기반 정렬**: 강력한 기록 또는 입증된 신뢰성을 가진 발신자는 우선순위가 부여되어 실패 및 재정렬의 위험을 줄입니다.
+- **제안자 기반 정렬**: 트랜잭션은 충돌을 최소화하고 처리량을 극대화하기 위해 번들을 구성하는 신뢰할 수 있는 제안자 노드에 의해 정렬될 수 있습니다.
+- **번들 이체 우선순위 지정**: 집계된 USDT 이체는 일반 트랜잭션보다 우선순위가 부여되어 종속성 충돌을 줄이고 더 깔끔한 실행 창을 확보합니다.
-Stable의 USDT 전송 애그리게이터는 일반 트랜잭션 처리를 저하시키지 않으면서 USDT0 전송의 처리량을 극대화하는 목표 최적화입니다. 병렬 실행, 모듈형 오류 처리, 스마트 정렬 전략을 결합하여 Stable은 스테이블코인 기반 경제를 위한 확장 가능한 기반을 제공합니다. 빠르고 빈번하며 마찰 없는 토큰 전송은 일반적입니다.
+Stable의 USDT 이체 어그리게이터는 일반 트랜잭션 처리를 저하시키지 않고 USDT0 이체의 처리량을 극대화하는 것을 목표로 하는 최적화입니다. 병렬 실행, 모듈형 오류 처리 및 스마트한 순서 지정 전략을 결합하여 Stable은 스테이블코인 기반 경제를 위한 확장 가능한 기반을 제공합니다. 빠르고 빈번하며 마찰 없는 토큰 이체가 표준입니다.
## 다음 권장 사항
-- [**결제 사용 사례**](/ko/explanation/payment-use-cases-overview): P2P, 구독, 종량제 등 집계된 처리량의 이점을 가장 많이 받는 결제 패턴을 확인하세요.
-- [**실행**](/ko/explanation/execution): 애그리게이터가 구축되는 병렬 실행 엔진을 확인하세요.
-- [**가스로서의 USDT**](/ko/explanation/usdt-as-gas-token): 애그리게이터가 이동하는 자산 모델을 이해하세요.
+- [**결제 사용 사례**](/ko/explanation/payment-use-cases-overview): 집계된 처리량의 이점을 가장 많이 받는 결제 패턴(P2P, 구독, 종량제)을 참조하세요.
+- [**실행**](/ko/explanation/execution): 어그리게이터가 구축하는 병렬 실행 엔진을 참조하세요.
+- [**USDT0을 가스로 사용**](/ko/explanation/usdt-as-gas-token): 어그리게이터가 이동하는 자산 모델을 이해하세요.
diff --git a/docs/pages/ko/explanation/usdt0-behavior.mdx b/docs/pages/ko/explanation/usdt0-behavior.mdx
index 1723795..777b8cc 100644
--- a/docs/pages/ko/explanation/usdt0-behavior.mdx
+++ b/docs/pages/ko/explanation/usdt0-behavior.mdx
@@ -1,37 +1,37 @@
---
source_path: explanation/usdt0-behavior.mdx
-source_sha: 17a1c5d1a4aae70266159154d52063d08fbb0378
-title: "Stable상의 USDT0 동작"
-description: "USDT0은 Stable에서 네이티브 자산이자 ERC-20 토큰으로 작동합니다. 잔액 조정, 허용량 안전성, opcode 동작에 대해 컨트랙트를 감사합니다."
+source_sha: 88ba67e3146da4f4e00e35291ef2e2270c9fa68c
+title: "Stable의 USDT0 동작"
+description: "USDT0는 Stable에서 기본 자산이자 ERC-20 토큰으로 작동합니다. 잔액 조정, 허용 범위 안전성 및 opcode 동작에 대한 계약을 감사합니다."
diataxis: "explanation"
---
-# Stable상의 USDT0 동작
+# Stable의 USDT0 동작
-**이더리움에서 컨트랙트를 포팅하는 경우 배포 전에 이 페이지를 읽어보세요.** Stable의 USDT0은 네이티브 가스 토큰이자 동일한 잔액에 있는 ERC-20 토큰입니다. 결과적으로 이더리움에서 가정하는 네 가지 동작이 깨집니다. 컨트랙트의 네이티브 잔액은 컨트랙트 호출 없이 변경될 수 있고, `EXTCODEHASH`는 0과 빈 해시 사이를 오갈 수 있으며, 0주소 전송은 되돌려지고, 단일 논리 전송은 부분 잔액 조정으로 인해 여러 `Transfer` 이벤트를 발생시킬 수 있습니다.
+**이더리움에서 계약을 포팅하는 경우, 배포하기 전에 이 페이지를 읽으십시오.** Stable의 USDT0는 기본 가스 토큰이자 동일한 잔액의 ERC-20 토큰입니다. 이로 인해 이더리움에서 가정되는 네 가지 동작이 깨집니다. 계약의 기본 잔액은 계약 호출 없이 변경될 수 있고, `EXTCODEHASH`는 0과 빈 해시 사이를 오갈 수 있으며, 0주소 전송은 되돌려지고, 단일 논리적 전송은 부분 잔액 조정으로 인해 여러 개의 `Transfer` 이벤트를 발생시킬 수 있습니다.
-이 페이지에서는 각 사례를 자세히 설명하고 안전한 컨트랙트 패턴을 제공합니다. 한 섹션만 읽는다면 [마이그레이션 체크리스트](#migration-checklist)를 읽어보세요. 이더리움 컨트랙트를 여기에 포팅하는 요약입니다.
+이 페이지에서는 각 사례를 살펴보고 안전한 계약 패턴을 제시합니다. 한 섹션만 읽는다면 [마이그레이션 체크리스트](#마이그레이션-체크리스트)를 읽으십시오. 이더리움 계약을 여기에 포팅하는 요약입니다.
## 이중 역할 개요
-Stable의 USDT0은 네이티브 가스 토큰이자 ERC-20 토큰입니다. 이 이중 역할 모델은 잔액 동작, 컨트랙트 설계 및 이벤트 처리에 영향을 미칩니다. 아래 섹션에서는 이중 역할로 인해 예상되는 동작이 변경되는 모든 경우를 설명합니다.
+Stable의 USDT0는 기본 가스 토큰이자 ERC-20 토큰입니다. 이 이중 역할 모델은 잔액 동작, 계약 설계 및 이벤트 처리에 영향을 미칩니다. 아래 섹션에서는 이중 역할이 예상되는 동작을 변경하는 모든 경우를 살펴봅니다.
-USDT0이 이러한 방식으로 작동하는 이유에 대한 배경 정보는 [USDT를 가스로](/ko/explanation/usdt-as-gas-token)를 참조하세요. 실제 전송을 통해 동작을 경험하려면 [첫 번째 USDT0 보내기](/ko/tutorial/send-usdt0)를 참조하세요.
+USDT0가 이런 방식으로 작동하는 이유에 대한 배경은 [가스로서의 USDT0](/ko/explanation/usdt-as-gas-token)를 참조하십시오. 실제 전송을 통해 동작을 경험하려면 [첫 USDT0 전송](/ko/tutorial/send-usdt0)을 참조하십시오.
## 잔액 조정
-USDT0은 네이티브 자산으로 18자릿수를 사용하고 ERC-20 토큰으로 6자릿수를 사용합니다. 네이티브 전송과 ERC-20 전송은 동일한 기본 잔액에서 작동하지만, 12자릿수 정밀도 차이는 전송에 소수점 이하의 정밀도가 포함될 때 시스템이 소수 부분을 조정해야 함을 의미합니다.
+USDT0는 기본 자산으로 18진수를 사용하고 ERC-20 토큰으로 6진수를 사용합니다. 기본 전송과 ERC-20 전송은 동일한 기본 잔액에서 작동하지만, 12자리 정밀도 차이는 전송에 서브 정수 정밀도가 포함될 때 시스템이 소수 금액을 조정해야 함을 의미합니다.
```text
-before
- 0.000001 USDT0 (ERC-20) + 0.000000000000000000 USDT0 (internal)
+이전
+ 0.000001 USDT0 (ERC-20) + 0.000000000000000000 USDT0 (내부)
// address(account).balance = 0.000001000000000000
// USDT0.balanceOf(account) = 0.000001
-if transfer 0.0000001 USDT0 to another account
+다른 계정으로 0.0000001 USDT0 전송 시
-after
- 0.000000 USDT0 (ERC-20) + 0.000000900000000000 USDT0 (internal)
+이후
+ 0.000000 USDT0 (ERC-20) + 0.000000900000000000 USDT0 (내부)
// address(account).balance = 0.000000900000000000
// USDT0.balanceOf(account) = 0.000000
```
@@ -40,30 +40,30 @@ after
## 이벤트 처리
-각 조정 전송은 추가 `Transfer` 이벤트를 발생시킵니다. 단일 논리적 USDT0 전송은 발신자와 수신자의 소수 부분 잔액이 어떻게 영향을 받는지에 따라 최대 두 개의 추가 `Transfer` 이벤트를 생성할 수 있습니다.
+각 조정 전송은 추가 `Transfer` 이벤트를 발생시킵니다. 단일 논리적 USDT0 전송은 발신자와 수신자의 소수 잔액이 어떻게 영향을 받는지에 따라 최대 두 개의 추가 `Transfer` 이벤트를 생성할 수 있습니다.
-- **발신자 조정**: 발신자의 소수 부분 잔액이 부족하면 0.000001 USDT0이 발신자에서 예약 주소로 이동됩니다. 이로 인해 추가 `Transfer` 이벤트가 발생합니다.
-- **수신자 조정**: 수신자의 소수 부분 잔액이 오버플로우되면 0.000001 USDT0이 예약 주소에서 수신자로 이동됩니다. 이로 인해 추가 `Transfer` 이벤트가 발생합니다.
-- **두 가지 조정 모두**: 동일한 전송에서 두 조건이 모두 발생하면 예약이 우회됩니다. 발신자는 메인 전송의 일부로 0.000001 USDT0을 수신자에게 직접 전송합니다. 추가 이벤트는 발생하지 않습니다.
+- **발신자 조정**: 발신자의 소수 잔액이 불충분하면 0.000001 USDT0가 발신자에서 예비 주소로 이동합니다. 이로 인해 추가 `Transfer` 이벤트가 발생합니다.
+- **수신자 조정**: 수신자의 소수 잔액이 오버플로되면 0.000001 USDT0가 예비 주소에서 수신자로 이동합니다. 이로 인해 추가 `Transfer` 이벤트가 발생합니다.
+- **모든 조정**: 두 조건이 동일한 전송에서 발생하면 예비가 우회됩니다. 발신자는 주 전송의 일부로 0.000001 USDT0를 수신자에게 직접 전송합니다. 추가 이벤트는 발생하지 않습니다.
-이러한 보조 이벤트는 예약 주소 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`와 관련이 있습니다. `Transfer` 이벤트를 다시 재생하여 USDT0 잔액을 추적하는 인덱서 및 오프체인 서비스는 이 주소로의 전송 및 이 주소로부터의 전송을 필터링하거나 고려해야 합니다.
+이러한 보조 이벤트는 예비 주소 `0x5113954bbC0eD721F1C68671EBa3d91e9e9bF7b5`를 포함합니다. `Transfer` 이벤트를 다시 재생하여 USDT0 잔액을 추적하는 인덱서 및 오프체인 서비스는 이 주소로의 전송 및 이 주소로부터의 전송을 필터링하거나 고려해야 합니다.
-## 컨트랙트 설계 요구 사항
+## 계약 설계 요구 사항
-### 네이티브 잔액 가변성
+### 기본 잔액 변경 가능성
-이더리움에서는 컨트랙트의 네이티브 잔액이 일반적으로 컨트랙트 실행의 결과로만 변경됩니다. Stable에서는 컨트랙트의 네이티브 USDT0 잔액이 ERC-20 허용 기반 작업(`transferFrom` 및 `permit` 포함)으로 인해 변경될 수도 있습니다. 이러한 작업은 컨트랙트 코드를 호출하지 않고도 컨트랙트의 네이티브 잔액을 줄일 수 있습니다.
+이더리움에서 계약의 기본 잔액은 일반적으로 계약 실행의 결과로만 변경됩니다. Stable에서는 계약의 기본 USDT0 잔액이 `transferFrom` 및 `permit`을 포함한 ERC-20 허용 기반 작업으로 인해 변경될 수도 있습니다. 이러한 작업은 계약 코드를 호출하지 않고도 계약의 기본 잔액을 줄일 수 있습니다.
결과적으로 다음 가정은 Stable에서 유효하지 않습니다.
-> 컨트랙트가 호출될 때만 컨트랙트의 네이티브 잔액이 줄어들 수 있습니다.
+> 계약의 기본 잔액은 계약이 호출되어야만 줄어들 수 있습니다.
-### 네이티브 잔액을 미러링하지 마십시오
+### 기본 잔액 미러링 금지
-이더리움에서는 내부 변수를 사용하여 예금을 추적하는 것이 일반적입니다. Stable에서는 ERC-20 `transferFrom`이 네이티브 잔액을 외부에서 소모할 수 있으므로 이는 안전하지 않습니다.
+이더리움에서는 예금을 내부 변수로 추적하는 것이 일반적입니다. Stable에서는 ERC-20 `transferFrom`이 외부적으로 기본 잔액을 소진할 수 있으므로 이는 안전하지 않습니다.
```solidity
-// Stable에서 UNSAFE
+// Stable에서 안전하지 않음
uint256 public deposited;
function deposit() external payable {
@@ -71,55 +71,55 @@ function deposit() external payable {
}
```
-### 전송 전에 항상 실제 잔액을 확인하십시오
+### 전송 직전에 항상 실제 잔액 확인
-모든 네이티브 값 전송은 전송 직전에 `address(this).balance`를 사용하여 지급 능력을 확인해야 하며, 내부 회계 변수가 아닙니다.
+모든 기본 가치 전송은 전송 직전에 `address(this).balance`를 사용하여 지급 능력을 확인해야 하며, 내부 회계 변수를 사용해서는 안 됩니다.
```solidity
-// SAFE
+// 안전함
function withdraw() external {
uint256 amount = credit[msg.sender];
credit[msg.sender] = 0;
- require(address(this).balance >= amount, "insufficient balance");
+ require(address(this).balance >= amount, "잔액 부족");
payable(msg.sender).call{value: amount}("");
}
```
-### 상태 진행은 잔액 독립적이어야 합니다
+### 상태 진행은 잔액 독립적이어야 합니다.
-진행, 마일스톤 또는 완료 조건에 의존하는 프로토콜 로직은 카운터 또는 에포크와 같은 비잔액 상태 변수를 사용하여 명시적으로 추적해야 합니다. 네이티브 잔액은 지불 시점의 지급 능력 확인에만 사용해야 합니다.
+진행, 이정표 또는 완료 조건에 의존하는 프로토콜 논리는 카운터 또는 에포크와 같은 비잔액 상태 변수를 사용하여 명시적으로 추적해야 합니다. 기본 잔액은 지불 시점의 지급 능력 확인에만 사용해야 합니다.
### 0주소 전송 금지
-Stable에서는 네이티브 및 ERC-20 전송을 `address(0)`으로 보내면 되돌려집니다.
+Stable에서는 `address(0)`로의 기본 및 ERC-20 전송은 모두 되돌려집니다.
```solidity
-// Stable에서 REVERT
+// Stable에서 되돌려짐
payable(address(0)).call{value: amount}("")
USDT0.transfer(address(0), amount);
```
-네이티브 USDT0을 보내는 모든 컨트랙트 로직은 전송 호출 전에 수신자를 확인하고 `address(0)`을 명시적으로 거부해야 합니다.
+기본 USDT0를 전송하는 계약 논리는 수신자를 검증하고 전송 호출 전에 `address(0)`를 명시적으로 거부해야 합니다.
```solidity
-// SAFE
-require(recipient != address(0), "zero address recipient");
+// 안전함
+require(recipient != address(0), "0 주소 수신자");
payable(recipient).call{value: amount}("");
```
-컨트랙트가 0주소 전송을 소각 메커니즘으로 사용하는 경우 재설계해야 합니다. 비가역적 손실 의미 체계가 필요한 경우 명시적 싱크 컨트랙트를 사용하십시오.
+계약이 0주소 전송을 소각 메커니즘으로 사용하는 경우 재설계해야 합니다. 되돌릴 수 없는 손실 의미론이 필요한 경우 명시적인 싱크 계약을 사용하십시오.
### EXTCODEHASH 동작
이더리움에서 `EXTCODEHASH` opcode는 다음을 반환합니다.
-- **0 해시**(`0x0000...`): 주소가 한 번도 사용되지 않은 경우(nonce=0, balance=0, 코드 없음).
-- **빈 해시**(`0xc5d2…a470`, 빈 코드의 Keccak-256 해시): 주소가 존재하지만 코드가 없는 경우.
+- **0 해시** (`0x0000...`): 주소가 사용된 적이 없는 경우 (nonce=0, balance=0, 코드 없음).
+- **빈 해시** (`0xc5d2…a470`, 빈 코드의 Keccak-256 해시): 주소가 존재하지만 코드가 없는 경우.
-이더리움에서 주소가 0 해시에서 빈 해시로 전환되면 다시 0 해시로 돌아갈 수 없습니다. Stable에서는 USDT0이 `permit()` 기반 승인을 지원하므로 주소는 트랜잭션을 보내지 않고도 승인을 생성할 수 있습니다. `transferFrom()`과 함께 사용하면 nonce 증가 없이 네이티브 잔액 변경이 가능하며, 이는 잠재적으로 `EXTCODEHASH`가 0 해시와 빈 해시 사이를 오갈 수 있도록 합니다.
+이더리움에서 주소가 0 해시에서 빈 해시로 전환되면 다시 0 해시로 돌아갈 수 없습니다. Stable에서는 USDT0가 `permit()` 기반 승인을 지원하므로 주소는 트랜잭션을 보내지 않고 승인을 생성할 수 있습니다. `transferFrom()`과 결합하면 nonce 증가 없이 기본 잔액 변경이 가능하며, `EXTCODEHASH`가 0 해시와 빈 해시 사이를 오갈 수 있습니다.
```solidity
-// Stable에서 UNSAFE
+// Stable에서 안전하지 않음
function isUnusedAddress(address addr) public view returns (bool) {
bytes32 codeHash;
assembly {
@@ -132,7 +132,7 @@ function isUnusedAddress(address addr) public view returns (bool) {
대신 명시적 추적을 사용하십시오.
```solidity
-// SAFE
+// 안전함
contract SafeAddressTracker {
mapping(address => bool) public hasBeenUsed;
@@ -150,38 +150,38 @@ contract SafeAddressTracker {
Stable 배포를 위한 테스트 스위트에는 다음이 포함되어야 합니다.
-- 허용 기반 소모 시나리오 (`approve` + `transferFrom`)
-- 실제 네이티브 잔액을 사용한 지급 능력 강제 적용
-- `EXTCODEHASH`에 의존하지 않는 주소 사용 로직
+- 허용 기반 소진 시나리오 (`approve` + `transferFrom`)
+- 실제 기본 잔액을 사용한 지급 능력 강제 적용
+- `EXTCODEHASH`에 의존하지 않는 주소 사용 논리
- 0주소 전송에 대한 명시적 오류 사례
## 마이그레이션 체크리스트
-이더리움에서 Stable로 컨트랙트를 포팅할 때:
+이더리움에서 Stable로 계약을 포팅할 때:
-- 내부 네이티브 잔액 미러 제거
-- 모든 지급 능력 검사를 `address(this).balance`로 대체
-- `address(0)`으로의 모든 네이티브 또는 ERC-20 전송 제거
+- 내부 기본 잔액 미러 제거
+- 모든 지급 능력 확인을 `address(this).balance`로 교체
+- `address(0)`로의 모든 기본 또는 ERC-20 전송 제거
- 모든 USDT0 승인 감사
-- `permit` 및 허용 기반 흐름을 다루는 테스트 추가
-- 오프체인 인덱서가 부분 잔액 조정에서 보조 `Transfer` 이벤트를 처리하는지 확인
+- `permit` 및 허용 기반 흐름을 포함하는 테스트 추가
+- 오프체인 인덱서가 부분 잔액 조정으로 인한 보조 `Transfer` 이벤트를 처리하는지 확인
## 주요 시사점
-Stable에서 올바른 컨트랙트 설계는 다음을 요구합니다.
+Stable에서 올바른 계약 설계를 위해서는 다음이 필요합니다.
-- USDT0을 이중 역할 자산으로 취급
+- USDT0를 이중 역할 자산으로 취급
- 실제 잔액에 대한 지급 능력 강제 적용
-- 허용 기반 소모 경로 방지
+- 허용 기반 소진 경로 방지
- 이더리움 특정 잔액 및 주소 가정에 대한 의존성 제거
오프체인 서비스 및 인덱서는 다음을 수행해야 합니다.
-- 부분 잔액 조정에서 보조 `Transfer` 이벤트 고려
-- 이벤트 기반 잔액 재구성 대신 직접 잔액 쿼리 사용
+- 부분 잔액 조정으로 인한 보조 `Transfer` 이벤트를 고려
+- 이벤트 기반 잔액 재구성이 아닌 직접 잔액 쿼리 사용
## 다음 권장 사항
-- [**USDT를 가스로 사용**](/ko/explanation/usdt-as-gas-token): USDT0이 네이티브 자산이면서 ERC-20 토큰으로 작동하는 이유를 이해합니다.
-- [**첫 번째 USDT0 보내기**](/ko/tutorial/send-usdt0): 네이티브 및 ERC-20 경로를 통해 테스트넷에서 USDT0 전송을 제출합니다.
+- [**가스로서의 USDT0**](/ko/explanation/usdt-as-gas-token): USDT0가 기본 자산이자 ERC-20 토큰으로 작동하는 이유를 이해합니다.
+- [**첫 USDT0 전송**](/ko/tutorial/send-usdt0): 기본 및 ERC-20 경로를 통해 테스트넷에서 USDT0 전송을 제출합니다.
- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 포팅할 때의 모든 동작 차이점을 검토합니다.
diff --git a/docs/pages/ko/explanation/usdt0-bridging.mdx b/docs/pages/ko/explanation/usdt0-bridging.mdx
index 64937b1..bac07a1 100644
--- a/docs/pages/ko/explanation/usdt0-bridging.mdx
+++ b/docs/pages/ko/explanation/usdt0-bridging.mdx
@@ -1,11 +1,151 @@
---
source_path: explanation/usdt0-bridging.mdx
-source_sha: e7c69b0ee925f0a348e16c6ca7a11c490739c061
-title: "USDT0를 Stable로 브리징하기"
-description: "USDT0와 네이티브 USDT가 OFT 메시와 레거시 메시를 통해 Stable에 도달하는 방법을 이해합니다."
+source_sha: e8ffad6d8ed33c1c3ffca3fece2da78a79369b10
+title: "USDT0를 Stable로 브리지하기"
+description: "USDT0 및 네이티브 USDT가 OFT 메시 및 레거시 메시를 통해 Stable에 도달하는 방법을 이해합니다."
diataxis: "explanation"
---
-# USDT0를 Stable로 브리징하기
+# USDT0를 Stable로 브리지하기
USDT는 소스 체인에서 어떤 형태를 취하는지에 따라 두 가지 브리지 경로 중 하나를 통해 Stable에 도달합니다. 두 경로 모두 USDT0를 Stable의 사용자 지갑으로 전달합니다.
+
+:::note
+**두 가지 경로, 한 가지 결과:**
+- **OFT 메시**: 소스 체인에 이미 USDT0이 있습니다. 소스에서 소각하고, Stable에서 발행합니다. 체인 간 1:1입니다. 예시: Arbitrum, Ethereum, Optimism, Polygon, Unichain, Ink, Bera, Mantle, Hyperliquid, MegaETH (총 21개 체인).
+- **레거시 메시**: 소스 체인에 네이티브 USDT만 있습니다. 허브로 Arbitrum을 통해 라우팅합니다. 전송 금액에 대해 0.03%의 수수료가 부과됩니다. 예시: Tron, TON.
+:::
+
+아래 섹션에서는 각 경로를 자세히 설명합니다.
+
+## USDT0 OFT 메시 대 레거시 메시
+
+Stable은 두 가지 보완적인 교차 체인 전송 네트워크에 참여합니다.
+
+### OFT 메시
+
+USDT0을 지원하는 모든 체인은 OFT 메시 에 참여할 수 있습니다. OFT 메시 내에서 USDT0 교차 체인 전송은 1:1 값 비율을 유지합니다. 전송이 발생하면 소스 체인의 USDT0 토큰이 소각되고 대상 체인에 동일한 양이 발행됩니다. 현재 OFT 메시 참가자에는 Arbitrum, Bera, Conflux, Ethereum, Flare, Hedera, Hyperliquid, Ink, Mantle, MegaETH, Monad, Morph, MP1, Optimism, Plasma, Polygon, Rootstock, Sei, Stable, Tempo, Unichain, X Layer가 있습니다.
+
+### 레거시 메시
+
+네이티브 USDT만 있는 (USDT0이 아닌) 모든 체인은 레거시 메시를 통해 라우팅할 수 있습니다. 레거시 메시 는 Arbitrum이 USDT0의 중앙 허브 역할을 하는 허브 앤 스포크 아키텍처를 따릅니다. 이 모델은 Arbitrum의 USDT0 유동성 풀을 활용합니다. USDT0 팀은 전송 금액에 대해 0.03%의 수수료를 부과합니다. 현재 레거시 메시 참가자에는 Tron과 TON이 있습니다.
+
+이더리움과 Arbitrum은 두 메시 모두에 참여합니다. 해당 체인의 사용자는 OFT 경로(USDT0 소각/발행) 또는 레거시 경로(Arbitrum 허브를 통해 네이티브 USDT 잠금)를 통해 브리지할 수 있습니다.
+
+---
+
+## 경로 1: USDT0를 Stable로 브리지하기 (OFT 지원 체인)
+
+이 경로는 사용자가 Arbitrum 또는 Ink와 같은 OFT 지원 소스 체인에 이미 USDT0를 보유하고 있을 때 적용됩니다.
+
+### 액터
+
+| 이름 | 온체인? | 책임 당사자 |
+| --- | --- | --- |
+| 사용자 | N/A | 사용자 |
+| USDT0 OUpgradable | ✅ | USDT0의 스마트 계약 |
+| LayerZero Endpoint V2 | ✅ | LayerZero의 스마트 계약 |
+| MessageLib Registry | ✅ | LayerZero의 스마트 계약 |
+| Executor | ❌ | LayerZero Labs |
+| USDT0 DVN | ❌ | USDT0 |
+| Canary DVN | ❌ | Canary |
+| LayerZero DVN | ❌ | LayerZero Labs |
+
+### 흐름도
+
+
+
+### 상세 단계
+
+#### 1. 전송 시작 (온체인, 소스 체인)
+
+사용자는 소스 체인의 **USDT0 OUpgradable** 계약에서 `lzSend` 메서드를 호출합니다. 트랜잭션에는 메시지 페이로드, 대상 LayerZero 엔드포인트 및 계약 주소, 가스 한도 및 수수료와 같은 구성 매개변수가 포함됩니다.
+
+#### 2. 패킷 생성 (온체인, 소스 체인)
+
+소스 LayerZero Endpoint는 OApp의 메시지를 패키징하고, 지정된 소스 MessageLib 계약을 사용하여 인코딩하며, 보안 스택(DVN) 및 Executor로 이를 발행하여 송신 트랜잭션을 완료합니다.
+
+#### 3. 메시지 검증 (오프체인, DVN)
+
+탈중앙화 검증자 네트워크(DVN)는 대상 계약이 메시지를 실행하기 전에 독립적으로 메시지를 검증합니다. OApp에 의해 승인된 DVN만 검증을 수행할 수 있습니다. USDT0 브리징에는 LayerZero Labs, Canary 및 USDT0의 세 가지 DVN이 모든 메시지에 서명해야 합니다. 모든 경로의 표준 구성은 [LayerZeroScan의 USDT0 OApp](https://layerzeroscan.com/)를 참조하세요.
+
+#### 4. 검증 가능으로 표시 (온체인, Stable)
+
+필요한 모든 DVN이 메시지를 검증하면 대상 MessageLib 계약은 이를 검증 가능으로 표시합니다.
+
+#### 5. 검증 확정 (오프체인, Executor)
+
+Executor는 검증된 메시지를 대상 LayerZero Endpoint에 커밋하여 실행을 준비합니다.
+
+#### 6. 패킷 유효성 검사 (온체인, Stable)
+
+대상 LayerZero Endpoint는 Executor가 전달한 패킷이 DVN에 의해 검증된 패킷과 일치하는지 확인합니다.
+
+#### 7. 메시지 실행 (오프체인, Executor)
+
+Executor는 대상 체인에서 `lzReceive`를 호출하여 Stable의 USDT0 OUpgradable 계약에 의한 메시지 처리를 트리거합니다.
+
+#### 8. 완료 (온체인, Stable)
+
+Stable의 USDT0 OUpgradable 계약은 검증된 메시지를 처리하여 교차 체인 전송을 완료합니다. USDT0는 사용자의 주소로 발행됩니다.
+
+---
+
+## 경로 2: 네이티브 USDT를 Stable로 브리지하기 (레거시 메시)
+
+이 경로는 사용자가 Tron과 같은 레거시 메시 체인에 네이티브 USDT를 보유하고 있을 때 적용됩니다. 전송은 Stable에 도착하기 전에 Arbitrum을 중간 허브로 거쳐 라우팅됩니다.
+
+### 액터
+
+| 이름 | 온체인? | 책임 당사자 |
+| --- | --- | --- |
+| 사용자 | N/A | 사용자 |
+| USDT Pool | ✅ | USDT0의 스마트 계약 |
+| USDT0 Pool | ✅ | USDT0의 스마트 계약 |
+| MultiHopComposer | ✅ | LayerZero의 스마트 계약 |
+| USDT0 OUpgradable | ✅ | USDT0의 스마트 계약 |
+| LayerZero Endpoint | ✅ | LayerZero의 스마트 계약 |
+| MessageLib Registry | ✅ | LayerZero의 스마트 계약 |
+| USDT0 Legacy Mesh Operator | ❌ | USDT0 |
+| Executor | ❌ | LayerZero Labs |
+| USDT0 DVN | ❌ | USDT0 |
+| Canary DVN | ❌ | Canary |
+| LayerZero DVN | ❌ | LayerZero Labs |
+
+### 흐름도
+
+
+
+### 상세 단계
+
+#### 1. 전송 시작 (온체인, Tron)
+
+사용자는 브리지 트랜잭션을 시작하고 네이티브 USDT를 Tron의 **USDT Pool** 계약으로 보냅니다. USDT는 풀에 잠깁니다. USDT Pool 계약은 Tron의 LayerZero Endpoint 계약으로 메시지를 보냅니다.
+
+#### 2. 레거시 메시로 메시지 보내기 (오프체인)
+
+LayerZero Endpoint 계약은 메시지를 **USDT0 Legacy Mesh Operator**로 발행하며, 이는 메시지를 검증합니다.
+
+#### 3. MultiHop 전송 시작 (온체인, Arbitrum)
+
+USDT0 Legacy Mesh Operator는 Arbitrum의 LayerZero **MultiHopComposer** 계약에서 `lzCompose()` 메서드를 호출합니다. 추가 사용자 상호 작용 없이 MultiHopComposer 계약은 Arbitrum에서 Stable로 USDT0 발행-소각 브리지 전송을 수행합니다.
+
+:::note
+MultiHopComposer 계약은 완전히 무허가이며 불변성을 보장하기 위해 `owner()`가 없습니다.
+:::
+
+#### 4. USDT0를 Stable로 전송 (온체인 및 오프체인)
+
+나머지 단계는 [USDT0를 Stable로 브리지하기](#path-1--bridging-usdt0-to-stable-oft-supported-chains) (위의 1-8단계)와 정확히 동일한 경로를 따릅니다. Arbitrum의 USDT0 OUpgradable 계약은 LayerZero를 통해 보내고, DVN이 검증하며, USDT0는 Stable에 발행됩니다.
+
+### 참고 사항
+
+- Arbitrum의 USDT0 유동성은 USDT0 팀이 관리합니다.
+- 레거시 메시에는 전송된 금액에 대해 0.03%의 수수료가 부과됩니다.
+- 사용자는 Arbitrum과 직접 상호 작용할 필요가 없으며 MultiHop 흐름은 자동입니다.
+
+## 다음 권장 사항
+
+- [**자금 흐름**](/ko/explanation/flow-of-funds): 온램프부터 정산까지 USDT의 전체 수명 주기를 확인하세요.
+- [**브리지 튜토리얼**](/ko/tutorial/bridge-usdt0): LayerZero OFT 어댑터를 사용하여 Sepolia에서 Stable 테스트넷으로 테스트 USDT를 브리지합니다.
+- [**USDT0 가스**](/ko/explanation/usdt-as-gas-token): 자산이 Stable에 도착하면 어떤 역할을 하는지 이해합니다.
diff --git a/docs/pages/ko/explanation/use-case-payments.mdx b/docs/pages/ko/explanation/use-case-payments.mdx
index d860ca5..2de20a7 100644
--- a/docs/pages/ko/explanation/use-case-payments.mdx
+++ b/docs/pages/ko/explanation/use-case-payments.mdx
@@ -1,27 +1,27 @@
---
source_path: explanation/use-case-payments.mdx
-source_sha: a5e26e7574265dccbb0f71370598384bdeeea5f6
+source_sha: 9685590c6fb8bb68a3a4b8be6c907bf5547d0372
title: "결제 및 이체"
-description: "Stable이 단일 자산 모델, 수수료 없는 UX, 즉각적인 완결성을 통해 P2P 결제 및 가맹점 정산을 지원하는 방법."
+description: "스테이블은 단일 자산 모델, 수수료 없는 UX, 즉각적인 완결성을 통해 P2P 결제 및 상인 정산을 지원하는 방법을 설명합니다."
diataxis: "explanation"
---
# 결제 및 이체
-자금을 이동하고 거래 비용을 지불하는 단일 자산을 중심으로 구축된 P2P 결제 및 가맹점 정산.
+자금을 이동하고 거래 비용을 지불하는 단일 자산을 중심으로 구축된 P2P 결제 및 상인 정산.
-## 문제점
+## 문제
-범용 체인에서 사용자는 스테이블코인을 이동하기 위해 별도의 가스 토큰(ETH, SOL)을 보유해야 합니다. 이는 "1달러를 보내면 1달러를 받는다"는 정신 모델을 깨고 온보딩 시 전환에 어려움을 줍니다. USDT만 가진 결제자는 이체 제출조차 할 수 없습니다.
+일반적인 블록체인에서 사용자는 스테이블 코인을 이동하기 위해 별도의 가스 토큰(ETH, SOL)을 보유해야 합니다. 이는 "1달러를 보내면 1달러를 받는다"는 정신적 모델을 깨뜨리고, 온보딩 단계에서 USDT만 가진 결제자가 이체를 제출할 수 없어 전환율이 떨어집니다.
-## Stable의 해결책
+## 스테이블이 이를 해결하는 방법
-- **USDT0는 가스 토큰이자 결제 자산입니다.** 사용자는 송금 또는 수신을 위해 하나의 자산만 있으면 됩니다. [가스용 USDT](/ko/explanation/usdt-as-gas-token)를 참조하세요.
-- **가스 면제는 애플리케이션이 사용자를 대신하여 가스를 지불할 수 있도록 하여**, 사용자가 두 번째 토큰을 사용할 필요 없이 수수료가 없는 UX를 가능하게 합니다. [가스 면제](/ko/explanation/gas-waiver)를 참조하세요.
-- **단일 슬롯 완결성은 정산이 즉시 이루어진다는 것을 의미합니다.** 일단 이체가 블록에 포함되면 즉시 확정됩니다. [이더리움 비교](/ko/explanation/ethereum-comparison)를 참조하세요.
+- **USDT0는 가스 토큰이자 결제 자산입니다.** 사용자는 송금 또는 수신을 위해 하나의 자산만 필요합니다. [가스용 USDT0](/ko/explanation/usdt-as-gas-token)를 참조하세요.
+- **가스 면제를 통해 애플리케이션은 사용자를 대신하여 가스 비용을 지불할 수 있습니다.** 이를 통해 사용자가 두 번째 토큰을 만질 필요 없이 수수료 없는 UX를 제공할 수 있습니다. [가스 면제](/ko/explanation/gas-waiver)를 참조하세요.
+- **단일 슬롯 완결성은 즉각적인 정산을 의미합니다.** 이체가 블록에 포함되면 즉시 확정됩니다. [이더리움 비교](/ko/explanation/ethereum-comparison)를 참조하세요.
## 다음 권장 사항
-- [**가스용 USDT**](/ko/explanation/usdt-as-gas-token): ETH를 대체하여 가스 및 결제에 동시에 사용되는 자산을 이해합니다.
-- [**가스 면제**](/ko/explanation/gas-waiver): 거버넌스 승인 면제 주소를 통해 애플리케이션이 사용자 가스를 처리하는 방법을 확인합니다.
-- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 이전할 때 변경되는 사항(완결성, 가스 토큰, 우선순위 팁)을 검토합니다.
+- [**가스용 USDT0**](/ko/explanation/usdt-as-gas-token): ETH를 대체하여 가스 및 결제에 동시에 사용되는 자산을 이해합니다.
+- [**가스 면제**](/ko/explanation/gas-waiver): 애플리케이션이 거버넌스 승인 면제 주소를 통해 사용자 가스를 어떻게 부담하는지 확인합니다.
+- [**이더리움 비교**](/ko/explanation/ethereum-comparison): 이더리움에서 이동할 때 무엇이 변경되는지(완결성, 가스 토큰, 우선순위 팁) 검토합니다.
diff --git a/docs/sidebar.json b/docs/sidebar.json
index c8d72c9..6423545 100644
--- a/docs/sidebar.json
+++ b/docs/sidebar.json
@@ -59,7 +59,7 @@
"collapsed": true,
"items": [
{
- "text": "Usdt Features Overview",
+ "text": "USDT0 features overview",
"link": "/en/explanation/usdt-features-overview"
},
{
@@ -75,11 +75,11 @@
"link": "/en/explanation/bridge-security"
},
{
- "text": "Usdt As Gas Token",
+ "text": "USDT0 as gas",
"link": "/en/explanation/usdt-as-gas-token"
},
{
- "text": "Usdt0 Behavior",
+ "text": "USDT0 behavior",
"link": "/en/explanation/usdt0-behavior"
},
{
@@ -91,7 +91,7 @@
"link": "/en/explanation/guaranteed-blockspace"
},
{
- "text": "Usdt Transfer Aggregator",
+ "text": "USDT Transfer Aggregator",
"link": "/en/explanation/usdt-transfer-aggregator"
},
{
@@ -277,7 +277,7 @@
"collapsed": true,
"items": [
{
- "text": "Send Usdt0",
+ "text": "Send your first USDT0",
"link": "/en/tutorial/send-usdt0"
},
{
@@ -285,11 +285,11 @@
"link": "/en/how-to/zero-gas-transactions"
},
{
- "text": "Work With Usdt Gas",
+ "text": "Work with USDT0 as gas",
"link": "/en/how-to/work-with-usdt-gas"
},
{
- "text": "Bridge Usdt0",
+ "text": "Bridge USDT0 to Stable",
"link": "/en/tutorial/bridge-usdt0"
}
]
@@ -747,7 +747,7 @@
"collapsed": true,
"items": [
{
- "text": "USDT 기능 개요",
+ "text": "USDT0 기능 개요",
"link": "/ko/explanation/usdt-features-overview"
},
{
@@ -755,15 +755,15 @@
"link": "/ko/explanation/flow-of-funds"
},
{
- "text": "USDT0를 Stable로 브리징",
+ "text": "USDT0 Stable 브리징",
"link": "/ko/explanation/usdt0-bridging"
},
{
- "text": "브리지 보안",
+ "text": "브릿지 보안",
"link": "/ko/explanation/bridge-security"
},
{
- "text": "가스 토큰으로서의 USDT",
+ "text": "USDT0 가스",
"link": "/ko/explanation/usdt-as-gas-token"
},
{
@@ -775,7 +775,7 @@
"link": "/ko/explanation/gas-waiver"
},
{
- "text": "보장된 블록 공간",
+ "text": "블록 공간 보장",
"link": "/ko/explanation/guaranteed-blockspace"
},
{
@@ -823,25 +823,25 @@
"collapsed": true,
"items": [
{
- "text": "사용 사례(결제)",
+ "text": "결제 사용 사례",
"link": "/ko/explanation/use-case-payments"
},
{
- "text": "사용 사례(급여)",
+ "text": "급여 사용 사례",
"link": "/ko/explanation/use-case-payroll"
},
{
- "text": "사용 사례(스폰서)",
+ "text": "스폰서 사용 사례",
"link": "/ko/explanation/use-case-sponsored"
},
{
- "text": "사용 사례(프라이빗)",
+ "text": "가상 사용 사례",
"link": "/ko/explanation/use-case-private"
}
]
},
{
- "text": "토크노믹스",
+ "text": "토큰노믹스",
"link": "/ko/reference/tokenomics"
},
{
@@ -905,15 +905,15 @@
"link": "/ko/explanation/enterprise-sdk"
},
{
- "text": "트랜잭션 릴레이",
+ "text": "트랜잭션 중계",
"link": "/ko/how-to/relay-with-gas-waiver"
},
{
- "text": "보장된 블록 공간",
+ "text": "블록 공간 보장",
"link": "/ko/how-to/send-guaranteed-transactions"
},
{
- "text": "보장된 릴레이 트랜잭션",
+ "text": "보장된 중계 트랜잭션",
"link": "/ko/how-to/guaranteed-relayed-transactions"
},
{
@@ -965,25 +965,25 @@
"collapsed": true,
"items": [
{
- "text": "USDT0 전송",
+ "text": "첫 USDT0 전송",
"link": "/ko/tutorial/send-usdt0"
},
{
- "text": "제로 가스 트랜잭션",
+ "text": "가스 없는 트랜잭션",
"link": "/ko/how-to/zero-gas-transactions"
},
{
- "text": "USDT 가스 사용",
+ "text": "USDT0를 가스로 사용",
"link": "/ko/how-to/work-with-usdt-gas"
},
{
- "text": "USDT0 브리지",
+ "text": "USDT0 Stable 브리징",
"link": "/ko/tutorial/bridge-usdt0"
}
]
},
{
- "text": "사용자 청구",
+ "text": "사용자 요금 청구",
"collapsed": true,
"items": [
{
@@ -991,7 +991,7 @@
"link": "/ko/how-to/build-p2p-payments"
},
{
- "text": "구독 및 수금",
+ "text": "구독 및 수집",
"link": "/ko/how-to/subscribe-and-collect"
},
{
@@ -1029,7 +1029,7 @@
"link": "/ko/reference/pay-per-call"
},
{
- "text": "향후 사용 사례",
+ "text": "예정된 사용 사례",
"link": "/ko/explanation/upcoming-use-cases"
}
]
@@ -1049,7 +1049,7 @@
"link": "/ko/explanation/contracts-guides"
},
{
- "text": "첫 번째 계약 배포",
+ "text": "첫 계약 배포",
"collapsed": true,
"items": [
{
@@ -1115,7 +1115,7 @@
"link": "/ko/reference/system-transactions-api"
},
{
- "text": "언바운딩 추적",
+ "text": "언본딩 추적",
"link": "/ko/how-to/track-unbonding"
},
{
@@ -1161,7 +1161,7 @@
"link": "/ko/reference/mainnet-information"
},
{
- "text": "메인넷 버전 기록",
+ "text": "메인넷 버전 이력",
"link": "/ko/reference/mainnet-version-history"
}
]
@@ -1175,7 +1175,7 @@
"link": "/ko/reference/testnet-information"
},
{
- "text": "테스트넷 버전 기록",
+ "text": "테스트넷 버전 이력",
"link": "/ko/reference/testnet-version-history"
},
{
@@ -1213,7 +1213,7 @@
"collapsed": true,
"items": [
{
- "text": "브리지",
+ "text": "브릿지",
"link": "/ko/reference/bridges"
},
{
@@ -1225,7 +1225,7 @@
"link": "/ko/reference/oracles"
},
{
- "text": "RPC 제공업체",
+ "text": "RPC 제공자",
"link": "/ko/reference/rpc-providers"
},
{
@@ -1251,7 +1251,7 @@
]
},
{
- "text": "운영 준비 상태",
+ "text": "운영 준비 태세",
"link": "/ko/how-to/production-readiness"
},
{
@@ -1325,11 +1325,11 @@
"link": "/ko/explanation/ai-agents-guides"
},
{
- "text": "x402 및 MPP를 통한 지불",
+ "text": "x402 및 MPP 통해 지불",
"collapsed": true,
"items": [
{
- "text": "x402",
+ "text": "X402",
"link": "/ko/explanation/x402"
},
{
@@ -1363,11 +1363,11 @@
"link": "/ko/how-to/develop-with-ai"
},
{
- "text": "에이전틱 촉진자",
+ "text": "에이전트 퍼실리테이터",
"link": "/ko/reference/agentic-facilitators"
},
{
- "text": "에이전틱 지갑",
+ "text": "에이전트 지갑",
"link": "/ko/reference/agentic-wallets"
}
]
@@ -1381,15 +1381,15 @@
"collapsed": true,
"items": [
{
- "text": "学习概览",
+ "text": "学习总览",
"link": "/cn/explanation/learn-overview"
},
{
- "text": "概览",
+ "text": "总览",
"link": "/cn/explanation/overview"
},
{
- "text": "技术概览",
+ "text": "技术总览",
"link": "/cn/explanation/tech-overview"
},
{
@@ -1405,7 +1405,7 @@
"link": "/cn/explanation/key-features"
},
{
- "text": "与以太坊的对比",
+ "text": "以太坊对比",
"link": "/cn/explanation/ethereum-comparison"
},
{
@@ -1435,7 +1435,7 @@
"collapsed": true,
"items": [
{
- "text": "USDT 功能概览",
+ "text": "USDT0 功能总览",
"link": "/cn/explanation/usdt-features-overview"
},
{
@@ -1443,7 +1443,7 @@
"link": "/cn/explanation/flow-of-funds"
},
{
- "text": "将 USDT0 桥接到 Stable",
+ "text": "将 USDT0 跨链至 Stable",
"link": "/cn/explanation/usdt0-bridging"
},
{
@@ -1451,7 +1451,7 @@
"link": "/cn/explanation/bridge-security"
},
{
- "text": "USDT 作为 Gas 代币",
+ "text": "USDT0 作为 Gas",
"link": "/cn/explanation/usdt-as-gas-token"
},
{
@@ -1467,11 +1467,11 @@
"link": "/cn/explanation/guaranteed-blockspace"
},
{
- "text": "USDT 转账聚合器",
+ "text": "USDT 交易聚合器",
"link": "/cn/explanation/usdt-transfer-aggregator"
},
{
- "text": "隐私转账",
+ "text": "保密转账",
"link": "/cn/explanation/confidential-transfer"
}
]
@@ -1481,7 +1481,7 @@
"collapsed": true,
"items": [
{
- "text": "核心优化概览",
+ "text": "核心优化总览",
"link": "/cn/explanation/core-optimization-overview"
},
{
@@ -1515,7 +1515,7 @@
"link": "/cn/explanation/use-case-payments"
},
{
- "text": "工资用例",
+ "text": "薪资用例",
"link": "/cn/explanation/use-case-payroll"
},
{
@@ -1547,11 +1547,11 @@
"collapsed": true,
"items": [
{
- "text": "构建概览",
+ "text": "构建总览",
"link": "/cn/explanation/build-overview"
},
{
- "text": "快速入门",
+ "text": "快速开始",
"link": "/cn/tutorial/quick-start"
},
{
@@ -1559,7 +1559,7 @@
"collapsed": true,
"items": [
{
- "text": "概览",
+ "text": "总览",
"link": "/cn/explanation/sdk-overview"
},
{
@@ -1575,11 +1575,11 @@
"link": "/cn/how-to/earn-yield"
},
{
- "text": "viem 集成",
+ "text": "Viem 集成",
"link": "/cn/how-to/sdk-with-viem"
},
{
- "text": "wagmi 集成",
+ "text": "Wagmi 集成",
"link": "/cn/how-to/sdk-with-wagmi"
}
]
@@ -1589,7 +1589,7 @@
"collapsed": true,
"items": [
{
- "text": "概览",
+ "text": "总览",
"link": "/cn/explanation/enterprise-sdk"
},
{
@@ -1601,7 +1601,7 @@
"link": "/cn/how-to/send-guaranteed-transactions"
},
{
- "text": "有保障的中继交易",
+ "text": "保证中继交易",
"link": "/cn/how-to/guaranteed-relayed-transactions"
},
{
@@ -1615,7 +1615,7 @@
"collapsed": true,
"items": [
{
- "text": "账户概览",
+ "text": "账户总览",
"link": "/cn/explanation/accounts-overview"
},
{
@@ -1641,7 +1641,7 @@
"collapsed": true,
"items": [
{
- "text": "支付概览",
+ "text": "支付总览",
"link": "/cn/explanation/payments-overview"
},
{
@@ -1649,11 +1649,11 @@
"link": "/cn/explanation/payments-guides"
},
{
- "text": "移动 USDT0",
+ "text": "转移 USDT0",
"collapsed": true,
"items": [
{
- "text": "发送 USDT0",
+ "text": "发送首笔 USDT0",
"link": "/cn/tutorial/send-usdt0"
},
{
@@ -1661,11 +1661,11 @@
"link": "/cn/how-to/zero-gas-transactions"
},
{
- "text": "使用 USDT Gas",
+ "text": "使用 USDT0 作为 Gas",
"link": "/cn/how-to/work-with-usdt-gas"
},
{
- "text": "桥接 USDT0",
+ "text": "将 USDT0 跨链到 Stable",
"link": "/cn/tutorial/bridge-usdt0"
}
]
@@ -1683,7 +1683,7 @@
"link": "/cn/how-to/subscribe-and-collect"
},
{
- "text": "凭发票支付",
+ "text": "发票付款",
"link": "/cn/how-to/pay-with-invoice"
}
]
@@ -1697,7 +1697,7 @@
"link": "/cn/explanation/erc-3009"
},
{
- "text": "支付用例概览",
+ "text": "支付用例总览",
"link": "/cn/explanation/payment-use-cases-overview"
},
{
@@ -1725,11 +1725,11 @@
]
},
{
- "text": "部署合约",
+ "text": "发布合约",
"collapsed": true,
"items": [
{
- "text": "合约概览",
+ "text": "合约总览",
"link": "/cn/explanation/contracts-overview"
},
{
@@ -1737,7 +1737,7 @@
"link": "/cn/explanation/contracts-guides"
},
{
- "text": "部署你的第一个合约",
+ "text": "部署首个合约",
"collapsed": true,
"items": [
{
@@ -1759,7 +1759,7 @@
"collapsed": true,
"items": [
{
- "text": "系统模块概览",
+ "text": "系统模块总览",
"link": "/cn/explanation/system-modules-overview"
},
{
@@ -1767,7 +1767,7 @@
"link": "/cn/how-to/use-system-modules"
},
{
- "text": "系统模块 API 概览",
+ "text": "系统模块 API 总览",
"link": "/cn/reference/system-modules-api-overview"
},
{
@@ -1803,11 +1803,11 @@
"link": "/cn/reference/system-transactions-api"
},
{
- "text": "跟踪解除绑定",
+ "text": "追踪解除绑定",
"link": "/cn/how-to/track-unbonding"
},
{
- "text": "索引验证器数据",
+ "text": "验证器数据索引",
"link": "/cn/how-to/index-validator-data"
}
]
@@ -1825,7 +1825,7 @@
"collapsed": true,
"items": [
{
- "text": "集成概览",
+ "text": "集成总览",
"link": "/cn/explanation/integrate-overview"
},
{
@@ -1921,7 +1921,7 @@
"link": "/cn/reference/network-routing"
},
{
- "text": "出入金",
+ "text": "法币通道",
"link": "/cn/reference/ramps"
},
{
@@ -1951,7 +1951,7 @@
"collapsed": true,
"items": [
{
- "text": "品牌套件",
+ "text": "品牌工具包",
"link": "/cn/resources/brand-kit"
}
]
@@ -1959,11 +1959,11 @@
]
},
{
- "text": "操作",
+ "text": "运营",
"collapsed": true,
"items": [
{
- "text": "节点操作概览",
+ "text": "节点运营总览",
"link": "/cn/reference/node-operations-overview"
},
{
@@ -2037,7 +2037,7 @@
"link": "/cn/how-to/build-mpp-endpoint"
},
{
- "text": "使用 MCP 支付",
+ "text": "通过 MCP 支付",
"link": "/cn/how-to/pay-with-mcp"
}
]
@@ -2047,7 +2047,7 @@
"collapsed": true,
"items": [
{
- "text": "使用 AI 进行开发",
+ "text": "利用 AI 开发",
"link": "/cn/how-to/develop-with-ai"
},
{