@ocap/client 1.28.6 → 1.28.7

package/docs/core-concepts-event-subscriptions.zh-TW.md

@@ -4,12 +4,14 @@ OCAP Client 提供一個功能強大、即時的事件訂閱系統，讓您的
 
 透過訂閱特定的事件主題，您可以接收到各種鏈上事件的即時通知，例如新交易建立、資產轉移或代幣交換。這對於建構能即時回應區塊鏈狀態變化的互動式應用程式至關重要。若想深入了解觸發這些事件的原因，您可以參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md)。
 
+
 ## 運作方式
 
 在底層，當您首次訂閱事件時，OCAP Client 會自動與區塊鏈節點的指定端點建立 WebSocket 連線。此連線會保持活動狀態，讓節點能在事件發生時立即將事件資料推送至您的客戶端。
 
 客戶端會為您管理 WebSocket 連線的生命週期。它會處理初始連線、發送心跳訊息以維持連線，並在連線中斷時嘗試重新連線。這確保了穩定可靠的事件流，而您只需進行最少的設定。
 
+
 ## 訂閱事件
 
 若要開始監聽事件，請使用 `subscribe` 方法。您需要提供一個事件主題（用於識別事件的字串）和一個回呼函式，該函式將在每次收到事件時執行。
@@ -38,12 +40,13 @@ client.subscribe('tx.create', handleNewTransaction);
 
 事件主題通常遵循 `tx.<transaction_type>` 的模式。以下是一些常見範例：
 
-| Topic | Description |
-|---|---|
-| `tx.create` | 任何新交易成功處理並加入區塊時觸發。 |
-| `tx.transfer_v2` | 當 `transferV2` 交易發生時特別觸發。 |
-| `tx.exchange_v2` | 當 `exchangeV2`（原子交換）交易完成時觸發。 |
-| `tx.create_asset` | 當新資產（NFT）被建立時觸發。 |
+| Topic             | Description                  |
+| ----------------- | ---------------------------- |
+| `tx.create`       | 任何新交易成功處理並加入區塊時觸發。           |
+| `tx.transfer_v2`  | 當 `transferV2` 交易發生時特別觸發。    |
+| `tx.exchange_v2`  | 當 `exchangeV2`（原子交換）交易完成時觸發。 |
+| `tx.create_asset` | 當新資產（NFT）被建立時觸發。             |
+
 
 ## 取消訂閱事件
 
@@ -66,6 +69,7 @@ client.unsubscribe('tx.create');
   <x-field data-name="callback" data-type="Function" data-required="false" data-desc="選用。要移除的特定回呼函式。如果省略，將移除該主題的所有監聽器。"></x-field>
 </x-field-group>
 
+
 ## 完整範例
 
 以下是一個完整範例，示範了訂閱事件、觸發事件，然後取消訂閱的過程。
@@ -116,8 +120,9 @@ const main = async () => {
 main().catch(console.error);
 ```
 
+
 ## 總結
 
 事件訂閱是使用 OCAP Client 建構動態 dApp 的核心功能。它們提供了一個簡單而強大的 API，可透過可靠的 WebSocket 連線即時回應鏈上事件。透過使用 `subscribe` 和 `unsubscribe` 方法，您可以有效率地管理應用程式中的即時資料流。
 
-有關如何建構和發送交易（進而產生這些事件）的更多詳細資訊，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。若要探索如何為您的使用者贊助交易費用（這在與事件監聽器結合使用時非常有用），請閱讀有關 [Gas 費用支付](./core-concepts-gas-payment.md) 的內容。
+有關如何建構和發送交易（進而產生這些事件）的更多詳細資訊，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。若要探索如何為您的使用者贊助交易費用（這在與事件監聽器結合使用時非常有用），請閱讀有關 [Gas 費用支付](./core-concepts-gas-payment.md) 的內容。

package/docs/core-concepts-event-subscriptions.zh.md

@@ -4,12 +4,14 @@ OCAP Client 提供了一个强大的实时事件订阅系统，允许您的应
 
 通过订阅特定的事件主题，您可以收到各种链上事件的即时通知，例如新交易创建、资产转移或代币交换。这对于构建能够实时响应区块链状态变化的响应式和交互式应用程序至关重要。要更深入地了解触发这些事件的原因，您可能需要查看[交易生命周期](./core-concepts-transaction-lifecycle.md)。
 
+
 ## 工作原理
 
 在底层，当您首次订阅事件时，OCAP Client 会自动与区块链节点的指定端点建立 WebSocket 连接。该连接会保持活动状态，允许节点在事件发生时立即将事件数据推送到您的客户端。
 
 客户端会为您管理 WebSocket 连接的生命周期。它会处理初始连接、发送心跳消息以保持连接活跃，并在连接断开时尝试重新连接。这确保了事件流的稳定可靠，而您只需进行最少的配置。
 
+
 ## 订阅事件
 
 要开始监听事件，您可以使用 `subscribe` 方法。您需要提供一个事件主题（用于标识事件的字符串）和一个回调函数，该函数会在收到事件时执行。
@@ -38,12 +40,13 @@ client.subscribe('tx.create', handleNewTransaction);
 
 事件主题通常遵循 `tx.<transaction_type>` 的模式。以下是一些常见示例：
 
-| Topic | Description |
-|---|---|
-| `tx.create` | 任何新交易成功处理并添加到区块时触发。 |
-| `tx.transfer_v2` | 当 `transferV2` 交易发生时专门触发。 |
-| `tx.exchange_v2` | 当 `exchangeV2`（原子交换）交易完成时触发。 |
-| `tx.create_asset` | 当新资产（NFT）创建时触发。 |
+| Topic             | Description                  |
+| ----------------- | ---------------------------- |
+| `tx.create`       | 任何新交易成功处理并添加到区块时触发。          |
+| `tx.transfer_v2`  | 当 `transferV2` 交易发生时专门触发。    |
+| `tx.exchange_v2`  | 当 `exchangeV2`（原子交换）交易完成时触发。 |
+| `tx.create_asset` | 当新资产（NFT）创建时触发。              |
+
 
 ## 取消订阅事件
 
@@ -66,6 +69,7 @@ client.unsubscribe('tx.create');
   <x-field data-name="callback" data-type="Function" data-required="false" data-desc="可选。要移除的特定回调函数。如果省略，该主题的所有监听器都将被移除。"></x-field>
 </x-field-group>
 
+
 ## 完整示例
 
 以下是一个完整的示例，演示了订阅事件、触发事件，然后取消订阅的整个过程。
@@ -116,8 +120,9 @@ const main = async () => {
 main().catch(console.error);
 ```
 
+
 ## 总结
 
 事件订阅是使用 OCAP Client 构建动态 dApp 的核心功能。它们提供了一个简单而强大的 API，通过可靠的 WebSocket 连接实时响应链上事件。通过使用 `subscribe` 和 `unsubscribe` 方法，您可以高效地管理应用程序中的实时数据流。
 
-有关如何构造和发送交易（这些交易会生成这些事件）的更多详细信息，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。要了解如何为您的用户代付交易费用（这在与事件监听器结合使用时非常有用），请阅读[燃料费支付](./core-concepts-gas-payment.md)。
+有关如何构造和发送交易（这些交易会生成这些事件）的更多详细信息，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。要了解如何为您的用户代付交易费用（这在与事件监听器结合使用时非常有用），请阅读[燃料费支付](./core-concepts-gas-payment.md)。

package/docs/core-concepts-gas-payment.ja.md

@@ -4,12 +4,13 @@
 
 この強力な機能により、dAppsはガスの複雑さを抽象化し、ユーザーのオンボーディングとアプリケーション全体のユーザビリティを向上させることができます。
 
+
 ## 仕組み
 
 ガス代行支払いの仕組みは、標準的なHTTPヘッダーを通じて実装されます。クライアントインスタンスにガス支払い者ウォレットを設定すると、クライアントはブロックチェーンノードに送信するすべての`sendTx`ミューテーションに、自動的に2つの特別なヘッダーを添付します：
 
-- `x-gas-payer-pk`: ガス料金を支払うウォレットの公開鍵。
-- `x-gas-payer-sig`: ガス支払い者の秘密鍵で署名されたJSON Web Token (JWT)。このトークンにはトランザクションのハッシュが含まれており、その特定のトランザクションの手数料を支払うというスポンサーからの検証可能な承認として機能します。
+* `x-gas-payer-pk`: ガス料金を支払うウォレットの公開鍵。
+* `x-gas-payer-sig`: ガス支払い者の秘密鍵で署名されたJSON Web Token (JWT)。このトークンにはトランザクションのハッシュが含まれており、その特定のトランザクションの手数料を支払うというスポンサーからの検証可能な承認として機能します。
 
 ブロックチェーンノードがトランザクションを受信すると、2つの重要な検証を実行します：
 
@@ -23,9 +24,12 @@
 以下の図は、トランザクションの開始から実行までのガス代行支払いの全フローを示しています：
 
 <!-- DIAGRAM_IMAGE_START:sequence:4:3 -->
+
 ![Gas Payment](assets/diagram/core-concepts-gas-payment-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## 使用例
 
 ガスレストランザクションを有効にするには、スポンサーアカウント用のウォレットインスタンスを作成し、`setGasPayer`メソッドを使用してクライアントに設定するだけです。
@@ -81,4 +85,4 @@ performGaslessTransaction();
 
 ---
 
-トランザクションの作成から確定までの全行程を理解するには、[トランザクションのライフサイクル](./core-concepts-transaction-lifecycle.md)のドキュメントを参照してください。
+トランザクションの作成から確定までの全行程を理解するには、[トランザクションのライフサイクル](./core-concepts-transaction-lifecycle.md)のドキュメントを参照してください。

package/docs/core-concepts-gas-payment.md

@@ -4,12 +4,13 @@ In most blockchain systems, every transaction requires a fee, commonly known as
 
 This powerful feature enables dApps to abstract away the complexity of gas, improving user onboarding and overall application usability.
 
+
 ## How It Works
 
 The gas payment mechanism is implemented through standard HTTP headers. When you configure a gas payer wallet on your client instance, the client automatically attaches two special headers to every `sendTx` mutation it sends to the blockchain node:
 
-- `x-gas-payer-pk`: The public key of the wallet that will pay the gas fee.
-- `x-gas-payer-sig`: A JSON Web Token (JWT) signed by the gas payer's secret key. This token contains the hash of the transaction, acting as a verifiable authorization from the sponsor to pay the fee for that specific transaction.
+* `x-gas-payer-pk`: The public key of the wallet that will pay the gas fee.
+* `x-gas-payer-sig`: A JSON Web Token (JWT) signed by the gas payer's secret key. This token contains the hash of the transaction, acting as a verifiable authorization from the sponsor to pay the fee for that specific transaction.
 
 When the blockchain node receives the transaction, it performs two critical validations:
 
@@ -23,9 +24,12 @@ If both signatures are valid, the transaction is executed under the user's autho
 The following diagram illustrates the entire gas payment flow from transaction initiation to execution:
 
 <!-- DIAGRAM_IMAGE_START:sequence:4:3 -->
+
 ![Gas Payment](assets/diagram/core-concepts-gas-payment-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## Usage Example
 
 To enable gasless transactions, you simply need to create a wallet instance for the sponsoring account and set it on the client using the `setGasPayer` method.
@@ -81,4 +85,4 @@ In this example, `userWallet` can successfully send a transaction even with a ze
 
 ---
 
-To understand the full journey of a transaction, from creation to finalization, see the [Transaction Lifecycle](./core-concepts-transaction-lifecycle.md) documentation.
+To understand the full journey of a transaction, from creation to finalization, see the [Transaction Lifecycle](./core-concepts-transaction-lifecycle.md) documentation.

package/docs/core-concepts-gas-payment.zh-TW.md

@@ -4,12 +4,13 @@
 
 這個強大的功能使 dApp 能夠將 Gas 的複雜性抽象化，從而改善使用者引導流程和整體應用程式的可用性。
 
+
 ## 運作方式
 
 Gas 支付機制是透過標準的 HTTP 標頭來實現的。當您在客戶端實例上設定 Gas 支付者錢包時，客戶端會自動將兩個特殊的標頭附加到它發送給區塊鏈節點的每個 `sendTx` 變更中：
 
-- `x-gas-payer-pk`：將支付 Gas 費用的錢包的公鑰。
-- `x-gas-payer-sig`：由 Gas 支付者私鑰簽署的 JSON Web Token (JWT)。此權杖包含交易的雜湊值，作為贊助者為該特定交易支付費用的可驗證授權。
+* `x-gas-payer-pk`：將支付 Gas 費用的錢包的公鑰。
+* `x-gas-payer-sig`：由 Gas 支付者私鑰簽署的 JSON Web Token (JWT)。此權杖包含交易的雜湊值，作為贊助者為該特定交易支付費用的可驗證授權。
 
 當區塊鏈節點收到交易時，它會執行兩項關鍵驗證：
 
@@ -23,9 +24,12 @@ Gas 支付機制是透過標準的 HTTP 標頭來實現的。當您在客戶端
 下圖說明了從交易發起到執行的整個 Gas 支付流程：
 
 <!-- DIAGRAM_IMAGE_START:sequence:4:3 -->
+
 ![Gas Payment](assets/diagram/core-concepts-gas-payment-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## 使用範例
 
 若要啟用免 Gas 交易，您只需為贊助帳戶建立一個錢包實例，並使用 `setGasPayer` 方法將其設定在客戶端上。
@@ -81,4 +85,4 @@ performGaslessTransaction();
 
 ---
 
-若要了解交易從建立到最終確認的完整過程，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。
+若要了解交易從建立到最終確認的完整過程，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。

package/docs/core-concepts-gas-payment.zh.md

@@ -4,12 +4,13 @@
 
 这一强大功能使 dApp 能够将 Gas 费的复杂性抽象出来，从而改善用户入门体验和应用的整体可用性。
 
+
 ## 工作原理
 
 Gas 费支付机制通过标准的 HTTP 标头实现。当您在客户端实例上配置一个 Gas 费支付方钱包时，客户端会自动将两个特殊的标头附加到它发送给区块链节点的每个 `sendTx` 变更请求中：
 
-- `x-gas-payer-pk`：将支付 Gas 费的钱包的公钥。
-- `x-gas-payer-sig`：由 Gas 费支付方私钥签名的 JSON Web Token (JWT)。此令牌包含交易的哈希值，作为支付方为该特定交易支付费用的可验证授权。
+* `x-gas-payer-pk`：将支付 Gas 费的钱包的公钥。
+* `x-gas-payer-sig`：由 Gas 费支付方私钥签名的 JSON Web Token (JWT)。此令牌包含交易的哈希值，作为支付方为该特定交易支付费用的可验证授权。
 
 当区块链节点收到交易时，它会执行两个关键验证：
 
@@ -23,9 +24,12 @@ Gas 费支付机制通过标准的 HTTP 标头实现。当您在客户端实例
 下图说明了从交易发起 Gas 费支付到执行的完整流程：
 
 <!-- DIAGRAM_IMAGE_START:sequence:4:3 -->
+
 ![Gas Payment](assets/diagram/core-concepts-gas-payment-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## 使用示例
 
 要启用无 Gas 费交易，您只需为代付账户创建一个钱包实例，并使用 `setGasPayer` 方法在客户端上进行设置。
@@ -81,4 +85,4 @@ performGaslessTransaction();
 
 ---
 
-要了解交易从创建到最终确认的完整过程，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。
+要了解交易从创建到最终确认的完整过程，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。

package/docs/core-concepts-transaction-lifecycle.ja.md

@@ -6,14 +6,18 @@ OCAP Client は柔軟なメソッドセットを提供しており、最大限
 
 このガイドでは、各段階を詳しく解説し、単一署名と複数署名の両方のワークフローを説明します。
 
+
 ## ライフサイクルの概要
 
 以下の図は、準備からブロックチェーンへの最終的な送信までのトランザクションの完全な流れを示しています。
 
 <!-- DIAGRAM_IMAGE_START:flowchart:4:3 -->
+
 ![Transaction Lifecycle](assets/diagram/core-concepts-transaction-lifecycle-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## ステージ1: 準備（`itx`の作成）
 
 すべてのトランザクションは `itx` (内部トランザクション) から始まります。これは、実行したいアクションの特定のデータを含むプレーンな JavaScript オブジェクトです。例えば、転送用の `itx` には、受信者のアドレスと金額が含まれます。
@@ -26,16 +30,17 @@ const itx = {
 };
 ```
 
+
 ## ステージ2: エンコード
 
 エンコードは、`itx` とその他のメタデータを、暗号学的に署名可能な標準化されたバイナリ形式に変換します。クライアントは、各トランザクションタイプごとに `encode{TxType}Tx` メソッド（例：`encodeTransferV2Tx`）を提供します。
 
 この段階で、クライアントは自動的に必須のメタデータを追加します。
 
-*   **`from`**: 送信者のアドレス。提供されたウォレットから派生します。
-*   **`chainId`**: ターゲットブロックチェーンの識別子。自動的に取得されます。
-*   **`nonce`**: リプレイ攻撃を防ぐためのユニークな番号。デフォルトでは現在のタイムスタンプ（`Date.now()`）になります。
-*   **`pk`**: 送信者ウォレットの公開鍵。
+* **`from`**: 送信者のアドレス。提供されたウォレットから派生します。
+* **`chainId`**: ターゲットブロックチェーンの識別子。自動的に取得されます。
+* **`nonce`**: リプレイ攻撃を防ぐためのユニークな番号。デフォルトでは現在のタイムスタンプ（`Date.now()`）になります。
+* **`pk`**: 送信者ウォレットの公開鍵。
 
 エンコード関数は、完全なトランザクションオブジェクトと、署名に使用されるシリアライズされたデータの `Buffer` の両方を返します。
 
@@ -49,6 +54,7 @@ console.log('Encoded TX Object:', encodedTx);
 console.log('Buffer to be signed:', txBuffer);
 ```
 
+
 ## ステージ3: 署名
 
 署名は、アカウントの所有権を証明し、トランザクションを承認するものです。このプロセスは、単一署名と複数署名のワークフローで異なります。
@@ -70,8 +76,8 @@ console.log('Signature:', signedTx.signature);
 
 複数署名（マルチシグ）トランザクションは、複数の当事者からの承認を必要とします。これは、アトミックスワップや共有アカウントで一般的に使用されます。プロセスは順次的に行われます。
 
-1.  **準備**: 最初のトランザクションは、必要なすべての署名者を定義する `signaturesList` とともに作成されます。
-2.  **順次署名**: トランザクションは署名者から次の署名者へと渡されます。各署名者は、対応する `multiSign{TxType}Tx` メソッドを使用して自身の署名を追加します。
+1. **準備**: 最初のトランザクションは、必要なすべての署名者を定義する `signaturesList` とともに作成されます。
+2. **順次署名**: トランザクションは署名者から次の署名者へと渡されます。各署名者は、対応する `multiSign{TxType}Tx` メソッドを使用して自身の署名を追加します。
 
 内部的に、`multiSign` メソッドは、署名のためにトランザクションをエンコードする前に、既存のすべての署名を一時的に取り除くことで、各当事者が全く同じトランザクションダイジェストに署名することを保証します。
 
@@ -97,6 +103,7 @@ console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
 console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
+
 ## ステージ4: 送信
 
 トランザクションが完全に署名されると、処理のためにブロックチェーンノードに送信できます。`send{TxType}Tx` メソッドがこの最終ステップを処理します。
@@ -118,8 +125,9 @@ console.log('Transaction sent! Hash:', hash);
 
 また、`commit: true` オプションを含めることで、プロミスが解決される前に、トランザクションが完全に確認され、ブロックに含まれるまでクライアントを待機させることもできます。
 
+
 ## まとめ
 
 トランザクションのライフサイクルは、ブロックチェーンと対話するための堅牢で柔軟なフレームワークを提供します。プロセスを準備、エンコード、署名、送信という明確な段階に分けることで、OCAP Client は開発者にトランザクション作成に対するきめ細やかな制御を提供すると同時に、一般的なユースケースのためのシンプルで高レベルなヘルパーも提供します。
 
-トランザクション手数料の処理方法に関する詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)のドキュメントを参照してください。
+トランザクション手数料の処理方法に関する詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)のドキュメントを参照してください。

package/docs/core-concepts-transaction-lifecycle.md

@@ -6,14 +6,18 @@ The OCAP Client provides a flexible set of methods that allow you to either perf
 
 This guide breaks down each stage and illustrates both single-signature and multi-signature workflows.
 
+
 ## Lifecycle Overview
 
 The following diagram illustrates the complete journey of a transaction from preparation to its final submission to the blockchain.
 
 <!-- DIAGRAM_IMAGE_START:flowchart:4:3 -->
+
 ![Transaction Lifecycle](assets/diagram/core-concepts-transaction-lifecycle-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## Stage 1: Preparation (Creating the `itx`)
 
 Every transaction begins with an `itx` (inner transaction). This is a plain JavaScript object that contains the specific data for the action you want to perform. For example, a transfer `itx` would include the recipient's address and the amount.
@@ -26,16 +30,17 @@ const itx = {
 };
 ```
 
+
 ## Stage 2: Encoding
 
 Encoding transforms the `itx` and other metadata into a standardized, binary format that can be cryptographically signed. The client provides an `encode{TxType}Tx` method for each transaction type (e.g., `encodeTransferV2Tx`).
 
 During this stage, the client automatically adds essential metadata:
 
-*   **`from`**: The sender's address, derived from the provided wallet.
-*   **`chainId`**: The identifier of the target blockchain, fetched automatically.
-*   **`nonce`**: A unique number to prevent replay attacks, which defaults to the current timestamp (`Date.now()`).
-*   **`pk`**: The public key of the sender's wallet.
+* **`from`**: The sender's address, derived from the provided wallet.
+* **`chainId`**: The identifier of the target blockchain, fetched automatically.
+* **`nonce`**: A unique number to prevent replay attacks, which defaults to the current timestamp (`Date.now()`).
+* **`pk`**: The public key of the sender's wallet.
 
 The encoding function returns both the full transaction object and a `Buffer` of the serialized data, which is used for signing.
 
@@ -49,6 +54,7 @@ console.log('Encoded TX Object:', encodedTx);
 console.log('Buffer to be signed:', txBuffer);
 ```
 
+
 ## Stage 3: Signing
 
 Signing proves ownership of the account and authorizes the transaction. The process differs for single-signature and multi-signature workflows.
@@ -70,8 +76,8 @@ console.log('Signature:', signedTx.signature);
 
 Multi-signature (multisig) transactions require approval from multiple parties. This is commonly used for atomic swaps or shared accounts. The process is sequential:
 
-1.  **Preparation**: The initial transaction is created with a `signaturesList` that defines all required signers.
-2.  **Sequential Signing**: The transaction is passed from one signer to the next. Each signer uses the corresponding `multiSign{TxType}Tx` method to add their signature.
+1. **Preparation**: The initial transaction is created with a `signaturesList` that defines all required signers.
+2. **Sequential Signing**: The transaction is passed from one signer to the next. Each signer uses the corresponding `multiSign{TxType}Tx` method to add their signature.
 
 Internally, the `multiSign` method ensures that each party signs the exact same transaction digest by temporarily stripping all existing signatures before encoding the transaction for signing.
 
@@ -97,6 +103,7 @@ console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
 console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
+
 ## Stage 4: Sending
 
 Once a transaction is fully signed, it can be sent to the blockchain node for processing. The `send{TxType}Tx` methods handle this final step.
@@ -118,8 +125,9 @@ console.log('Transaction sent! Hash:', hash);
 
 You can also include a `commit: true` option to make the client wait until the transaction is fully confirmed and included in a block before resolving the promise.
 
+
 ## Summary
 
 The transaction lifecycle provides a robust and flexible framework for interacting with the blockchain. By breaking the process into distinct stages—Preparation, Encoding, Signing, and Sending—the OCAP Client offers developers granular control over transaction creation while also providing simple, high-level helpers for common use cases.
 
-For more details on how transaction fees are handled, see the [Gas Payment](./core-concepts-gas-payment.md) guide. To understand the different client types available, refer to the [Client Architecture](./core-concepts-client-architecture.md) documentation.
+For more details on how transaction fees are handled, see the [Gas Payment](./core-concepts-gas-payment.md) guide. To understand the different client types available, refer to the [Client Architecture](./core-concepts-client-architecture.md) documentation.

package/docs/core-concepts-transaction-lifecycle.zh-TW.md

@@ -6,14 +6,18 @@ OCAP 用戶端提供了一套彈性的方法，讓您可以為了最大程度的
 
 本指南將分解每個階段，並闡述單一簽章和多重簽章的工作流程。
 
+
 ## 生命週期總覽
 
 下圖說明了一筆交易從準備到最終提交至區塊鏈的完整過程。
 
 <!-- DIAGRAM_IMAGE_START:flowchart:4:3 -->
+
 ![Transaction Lifecycle](assets/diagram/core-concepts-transaction-lifecycle-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## 階段 1：準備 (創建 `itx`)
 
 每筆交易都始於一個 `itx`（內部交易）。這是一個純 JavaScript 物件，其中包含您想執行操作的特定資料。例如，一個轉帳 `itx` 會包含收款人地址和金額。
@@ -26,16 +30,17 @@ const itx = {
 };
 ```
 
+
 ## 階段 2：編碼
 
 編碼是將 `itx` 和其他元資料轉換為可進行密碼學簽署的標準化二進位格式。用戶端為每種交易類型提供了一個 `encode{TxType}Tx` 方法（例如 `encodeTransferV2Tx`）。
 
 在此階段，用戶端會自動添加必要的元資料：
 
-*   **`from`**：發送方地址，從提供的錢包中衍生而來。
-*   **`chainId`**：目標區塊鏈的識別碼，會自動獲取。
-*   **`nonce`**：一個用來防止重放攻擊的唯一數字，預設為當前時間戳 (`Date.now()`)。
-*   **`pk`**：發送方錢包的公鑰。
+* **`from`**：發送方地址，從提供的錢包中衍生而來。
+* **`chainId`**：目標區塊鏈的識別碼，會自動獲取。
+* **`nonce`**：一個用來防止重放攻擊的唯一數字，預設為當前時間戳 (`Date.now()`)。
+* **`pk`**：發送方錢包的公鑰。
 
 編碼函式會返回完整的交易物件和序列化資料的 `Buffer`，後者用於簽署。
 
@@ -49,6 +54,7 @@ console.log('Encoded TX Object:', encodedTx);
 console.log('Buffer to be signed:', txBuffer);
 ```
 
+
 ## 階段 3：簽署
 
 簽署證明了帳戶的所有權並授權該筆交易。單一簽章和多重簽章工作流程的過程有所不同。
@@ -70,8 +76,8 @@ console.log('Signature:', signedTx.signature);
 
 多重簽章（multisig）交易需要多方批准。這通常用於原子交換或共享帳戶。這個過程是循序的：
 
-1.  **準備**：創建初始交易時，會帶有一個 `signaturesList`，其中定義了所有必要的簽署人。
-2.  **循序簽署**：交易從一個簽署人傳遞給下一個。每個簽署人都會使用對應的 `multiSign{TxType}Tx` 方法來添加自己的簽章。
+1. **準備**：創建初始交易時，會帶有一個 `signaturesList`，其中定義了所有必要的簽署人。
+2. **循序簽署**：交易從一個簽署人傳遞給下一個。每個簽署人都會使用對應的 `multiSign{TxType}Tx` 方法來添加自己的簽章。
 
 在內部，`multiSign` 方法會透過在編碼交易以進行簽署前，暫時移除所有現有簽章，來確保每一方都簽署完全相同的交易摘要。
 
@@ -97,6 +103,7 @@ console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
 console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
+
 ## 階段 4：發送
 
 一旦交易被完整簽署，就可以將其發送到區塊鏈節點進行處理。`send{TxType}Tx` 方法處理這最後一步。
@@ -118,8 +125,9 @@ console.log('Transaction sent! Hash:', hash);
 
 您也可以加入 `commit: true` 選項，讓用戶端等到交易完全確認並被納入一個區塊後，才解析該 promise。
 
+
 ## 總結
 
 交易生命週期為與區塊鏈互動提供了一個穩健而彈性的框架。透過將過程分解為不同的階段——準備、編碼、簽署和發送——OCAP 用戶端為開發者提供了對交易創建的精細控制，同時也為常見用例提供了簡單的高階輔助函式。
 
-有關交易費用如何處理的更多詳情，請參閱 [Gas 支付](./core-concepts-gas-payment.md) 指南。要了解可用的不同用戶端類型，請參閱 [用戶端架構](./core-concepts-client-architecture.md) 文件。
+有關交易費用如何處理的更多詳情，請參閱 [Gas 支付](./core-concepts-gas-payment.md) 指南。要了解可用的不同用戶端類型，請參閱 [用戶端架構](./core-concepts-client-architecture.md) 文件。

package/docs/core-concepts-transaction-lifecycle.zh.md

@@ -6,14 +6,18 @@ OCAP 客户端提供了一套灵活的方法，允许您单独执行这些步骤
 
 本指南将分解每个阶段，并说明单签名和多签名工作流。
 
+
 ## 生命周期概览
 
 下图展示了一笔交易从准备到最终提交至区块链的完整过程。
 
 <!-- DIAGRAM_IMAGE_START:flowchart:4:3 -->
+
 ![Transaction Lifecycle](assets/diagram/core-concepts-transaction-lifecycle-01.jpg)
+
 <!-- DIAGRAM_IMAGE_END -->
 
+
 ## 阶段 1：准备（创建 `itx`）
 
 每笔交易都始于一个 `itx`（内部交易）。这是一个纯 JavaScript 对象，包含了您想要执行的操作的具体数据。例如，一个转账 `itx` 会包含接收者的地址和金额。
@@ -26,16 +30,17 @@ const itx = {
 };
 ```
 
+
 ## 阶段 2：编码
 
 编码将 `itx` 和其他元数据转换为可进行加密签名的标准化二进制格式。客户端为每种交易类型都提供了一个 `encode{TxType}Tx` 方法（例如 `encodeTransferV2Tx`）。
 
 在此阶段，客户端会自动添加必要的元数据：
 
-*   **`from`**：发送者地址，从提供的钱包派生。
-*   **`chainId`**：目标区块链的标识符，自动获取。
-*   **`nonce`**：用于防止重放攻击的唯一数字，默认为当前时间戳 (`Date.now()`)。
-*   **`pk`**：发送者钱包的公钥。
+* **`from`**：发送者地址，从提供的钱包派生。
+* **`chainId`**：目标区块链的标识符，自动获取。
+* **`nonce`**：用于防止重放攻击的唯一数字，默认为当前时间戳 (`Date.now()`)。
+* **`pk`**：发送者钱包的公钥。
 
 编码函数返回完整的交易对象和用于签名的序列化数据 `Buffer`。
 
@@ -49,6 +54,7 @@ console.log('Encoded TX Object:', encodedTx);
 console.log('Buffer to be signed:', txBuffer);
 ```
 
+
 ## 阶段 3：签名
 
 签名证明了账户的所有权并授权了该交易。单签名和多签名工作流的流程有所不同。
@@ -70,8 +76,8 @@ console.log('Signature:', signedTx.signature);
 
 多重签名（multisig）交易需要多方批准。这通常用于原子交换或共享账户。该过程是顺序的：
 
-1.  **准备**：创建初始交易时，需包含一个 `signaturesList`，其中定义了所有必需的签名者。
-2.  **顺序签名**：交易从一个签名者传递到下一个。每个签名者使用相应的 `multiSign{TxType}Tx` 方法来添加他们的签名。
+1. **准备**：创建初始交易时，需包含一个 `signaturesList`，其中定义了所有必需的签名者。
+2. **顺序签名**：交易从一个签名者传递到下一个。每个签名者使用相应的 `multiSign{TxType}Tx` 方法来添加他们的签名。
 
 在内部，`multiSign` 方法通过在编码交易进行签名之前临时剥离所有现有签名，来确保各方签署完全相同的交易摘要。
 
@@ -97,6 +103,7 @@ console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
 console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
+
 ## 阶段 4：发送
 
 一旦交易被完全签名，就可以将其发送到区块链节点进行处理。`send{TxType}Tx` 方法处理这最后一步。
@@ -118,8 +125,9 @@ console.log('Transaction sent! Hash:', hash);
 
 您还可以包含一个 `commit: true` 选项，使客户端在解析 promise 之前，等待交易被完全确认并包含在区块中。
 
+
 ## 总结
 
 交易生命周期为与区块链交互提供了一个强大而灵活的框架。通过将过程分解为不同的阶段——准备、编码、签名和发送——OCAP 客户端为开发人员提供了对交易创建的精细控制，同时也为常见用例提供了简单的高级辅助函数。
 
-有关交易费用处理的更多详细信息，请参阅[燃料费支付](./core-concepts-gas-payment.md)指南。要了解可用的不同客户端类型，请参阅[客户端架构](./core-concepts-client-architecture.md)文档。
+有关交易费用处理的更多详细信息，请参阅[燃料费支付](./core-concepts-gas-payment.md)指南。要了解可用的不同客户端类型，请参阅[客户端架构](./core-concepts-client-architecture.md)文档。

package/docs/core-concepts.ja.md

@@ -19,4 +19,4 @@
   </x-card>
 </x-cards>
 
-これらの基礎的なトピックを把握することで、OCAP Clientを使用して、堅牢でスケーラブル、かつユーザーフレンドリーなアプリケーションを構築するための十分な準備が整います。
+これらの基礎的なトピックを把握することで、OCAP Clientを使用して、堅牢でスケーラブル、かつユーザーフレンドリーなアプリケーションを構築するための十分な準備が整います。

package/docs/core-concepts.md

@@ -19,4 +19,4 @@ While the [How-to Guides](./how-to-guides.md) provide step-by-step instructions
   </x-card>
 </x-cards>
 
-By grasping these foundational topics, you'll be well-equipped to build robust, scalable, and user-friendly applications using the OCAP Client.
+By grasping these foundational topics, you'll be well-equipped to build robust, scalable, and user-friendly applications using the OCAP Client.

package/docs/core-concepts.zh-TW.md

@@ -19,4 +19,4 @@
   </x-card>
 </x-cards>
 
-透過掌握這些基礎主題，您將具備足夠的能力，使用 OCAP Client 來建構穩健、可擴展且使用者友善的應用程式。
+透過掌握這些基礎主題，您將具備足夠的能力，使用 OCAP Client 來建構穩健、可擴展且使用者友善的應用程式。

package/docs/core-concepts.zh.md

@@ -19,4 +19,4 @@
   </x-card>
 </x-cards>
 
-通过掌握这些基础主题，您将能更好地使用 OCAP Client 构建稳健、可扩展且用户友好的应用程序。
+通过掌握这些基础主题，您将能更好地使用 OCAP Client 构建稳健、可扩展且用户友好的应用程序。

package/docs/getting-started-basic-usage.ja.md

@@ -4,6 +4,7 @@
 
 このガイドに従うことで、わずか数分でブロックチェーンとやり取りできる、動作可能なクライアントインスタンスを準備できます。
 
+
 ## 1. クライアントの初期化
 
 まず、`@ocap/client`パッケージをインポートし、`GraphQLClient`のインスタンスを作成する必要があります。コンストラクタは、接続したいブロックチェーンノードのGraphQLエンドポイントを引数に取ります。このガイドでは、ArcBlockベータチェーンの公開エンドポイントを使用します。
@@ -19,6 +20,7 @@ console.log('OCAP Client initialized!');
 
 これにより、チェーンへのクエリ、トランザクションの送信などのメソッドが事前設定されたクライアントインスタンスが作成されます。
 
+
 ## 2. ブロックチェーンへのクエリ
 
 クライアントが初期化されたので、簡単な読み取り専用操作を実行して接続を確認できます。`getChainInfo`メソッドは、接続されたブロックチェーンに関する基本情報を取得し、認証を必要としないため、この目的に最適です。
@@ -36,6 +38,7 @@ console.log('OCAP Client initialized!');
 
 リクエストが成功すると、`info`オブジェクトがコンソールに出力されます。これには、チェーンのID、ネットワーク、サポートされているトランザクションタイプなどの詳細が含まれます。これにより、クライアントがブロックチェーンノードと正常に通信していることが確認できます。
 
+
 ## 3. アカウントの準備
 
 トランザクション（書き込み操作）を送信するには、ウォレットが必要です。新しいウォレットはローカルで生成できます。このウォレットは、あなたのオンチェーンアカウントのアイデンティティを表します。
@@ -60,6 +63,7 @@ console.log('SecretKey:', wallet.secretKey);
   フォーセットにアクセスし、新しく生成したアドレスにTBAを送信して有効化してください。
 </x-card>
 
+
 ## 4. アカウント状態のクエリ
 
 フォーセットを使用して新しいアカウントに資金を供給したら、その状態をクエリして残高を確認できます。
@@ -80,8 +84,9 @@ console.log('SecretKey:', wallet.secretKey);
 
 レスポンスの`state`オブジェクトには、アカウントのアドレス、残高、nonce（送信済みトランザクション数）、その他の詳細が含まれます。ゼロ以外の残高が表示されれば、アカウントがフォーセットからトークンを受け取り、ブロックチェーン上で有効になったことが確認できます。
 
+
 ## 次のステップ
 
 これで、OCAP Clientのセットアップ、ブロックチェーンへの接続、アカウントの確認が正常に完了しました。より高度な操作を探求する準備が整いました。
 
-トークンの転送、アセットの管理などの一般的なタスクを実行する方法については、[ハウツーガイド](./how-to-guides.md)をご覧ください。
+トークンの転送、アセットの管理などの一般的なタスクを実行する方法については、[ハウツーガイド](./how-to-guides.md)をご覧ください。