@ocap/client 1.25.3 → 1.25.5

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

@@ -0,0 +1,111 @@
+# Gas 支付
+
+在大多數區塊鏈系統中，每筆交易都需要發起人支付一筆費用，通常稱為「gas」。對於可能沒有原生貨幣來支付這些費用的新使用者來說，這可能是一個重大的障礙。OCAP Client 引入了 Gas 支付功能，允許應用程式開發者贊助這些費用，為其使用者創造無縫的「無 gas」體驗。
+
+這個強大的功能使 dApps 能夠將 gas 的複雜性抽離，從而改善使用者引導流程和應用程式的整體可用性。
+
+## 運作原理
+
+Gas 支付機制是透過標準的 HTTP 標頭實現的。當您在您的客戶端實例上配置一個 gas 支付者錢包時，客戶端會自動將兩個特殊的標頭附加到它發送到區塊鏈節點的每個 `sendTx` 變異中：
+
+- `x-gas-payer-pk`：將支付 gas 費用的錢包的公鑰。
+- `x-gas-payer-sig`：由 gas 支付者的私鑰簽署的 JSON Web Token (JWT)。此權杖包含交易的雜湊值，作為贊助商為該特定交易支付費用的可驗證授權。
+
+當區塊鏈節點收到交易時，它會執行兩項關鍵的驗證：
+
+1. 它會驗證使用者在交易本身上的簽名。
+2. 它會根據交易雜湊值，驗證標頭中 gas 支付者的簽名。
+
+如果兩個簽名都有效，交易將以使用者的權限執行，但相應的 gas 費用會從 gas 支付者的帳戶餘額中扣除。
+
+### 工作流程圖
+
+下圖說明了從交易發起到執行的整個 gas 支付流程：
+
+```d2 Gas 支付工作流程 icon=mdi:gas-station
+direction: down
+
+User-App: {
+  label: "使用者應用程式"
+  shape: rectangle
+}
+
+Gas-Payer-Wallet: {
+  label: "Gas 支付者錢包\n（應用程式後端錢包）"
+  shape: cylinder
+}
+
+OCAP-Client: {
+  label: "OCAP Client 實例"
+}
+
+Blockchain-Node: {
+  label: "區塊鏈節點"
+  shape: rectangle
+}
+
+User-App -> OCAP-Client: "1. 使用者發起交易"
+OCAP-Client -> OCAP-Client: "2. 使用使用者錢包\n準備並簽署交易"
+Gas-Payer-Wallet -> OCAP-Client: "3. 為 gas 簽署交易雜湊"
+OCAP-Client -> Blockchain-Node: "4. 發送交易 + Gas 支付者標頭"
+Blockchain-Node -> Blockchain-Node: "5. 驗證雙方簽名"
+Blockchain-Node: "6. 執行交易"
+Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 gas 費用"
+```
+
+## 使用範例
+
+要啟用無 gas 交易，您只需為贊助帳戶創建一個錢包實例，並使用 `setGasPayer` 方法在客戶端上設定它。
+
+```javascript Gas 支付者設定與使用 icon=logos:javascript
+import Client from '@ocap/client';
+import Wallet, { fromRandom } from '@ocap/wallet';
+
+// 1. 初始化客戶端以連接到 Beta 鏈
+const client = new Client('https://beta.abtnetwork.io/api');
+
+// 2. 為 gas 支付者（您的應用程式錢包）創建一個錢包
+// 此錢包必須有足夠的原生代幣（TBA）來支付交易費用。
+// 您可以從水龍頭獲取測試代幣：https://faucet.abtnetwork.io/
+const gasPayerWallet = Wallet.fromJSON({
+  sk: '...your_sponsor_secret_key...',
+  pk: '...your_sponsor_public_key...',
+  address: '...your_sponsor_address...',
+});
+
+// 3. 在客戶端實例上設定 gas 支付者
+client.setGasPayer(gasPayerWallet);
+
+// 4. 為終端使用者創建一個錢包。
+const userWallet = fromRandom();
+
+// 5. 使用使用者的錢包發送一筆交易。
+// 該交易由使用者簽署，但 gas 費用由 gasPayerWallet 支付。
+async function performGaslessTransaction() {
+  try {
+    // 注意：雖然新帳戶在收到第一筆傳入交易時會在鏈上創建，
+    // 但它必須先存在於鏈上，才能*發送*交易。
+    // 您可以透過從水龍頭向其發送少量代幣來進行初始化。
+
+    const receiverAddress = 'z1...'; // 一個有效的收款人地址
+    const hash = await client.transfer({
+      to: receiverAddress,
+      tokens: [{ value: '0.1' }], // 發送 0.1 TBA
+      wallet: userWallet,
+    });
+
+    console.log('無 gas 交易成功。雜湊值：', hash);
+    console.log(`在區塊鏈瀏覽器上查看：https://beta.abtnetwork.io/explorer/txs/${hash}`);
+  } catch (error) {
+    console.error('交易失敗：', error);
+  }
+}
+
+performGaslessTransaction();
+```
+
+在此範例中，`userWallet` 即使原生代幣餘額為零，也可以成功發送交易，因為 `gasPayerWallet` 支付了費用。這創造了一種順暢的體驗，特別是對於加入您應用程式的新使用者。
+
+---
+
+要了解交易從創建到最終確定的完整過程，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。

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

@@ -0,0 +1,111 @@
+# Gas 支付
+
+在大多数区块链系统中，每笔交易都需要发起者支付一笔费用，通常称为“gas”。对于没有原生货币来支付这些费用的新用户来说，这可能是一个巨大的障碍。OCAP Client 引入了 Gas 支付功能，允许应用程序开发者代付这些费用，从而为用户创造无缝的、“无 gas”体验。
+
+这一强大功能使 dApp 能够屏蔽 gas 的复杂性，从而改善用户引导流程和应用的整体易用性。
+
+## 工作原理
+
+gas 支付机制通过标准的 HTTP 标头实现。当您在客户端实例上配置 gas 代付方钱包时，客户端会自动将两个特殊的标头附加到它发送给区块链节点的每个 `sendTx` mutation 请求中：
+
+- `x-gas-payer-pk`：将支付 gas 费用的钱包的公钥。
+- `x-gas-payer-sig`：由 gas 代付方私钥签名的 JSON Web Token (JWT)。此令牌包含交易的哈希值，作为代付方为该特定交易支付费用的可验证授权。
+
+当区块链节点收到交易时，它会执行两项关键验证：
+
+1. 验证用户在交易本身的签名。
+2. 根据交易哈希验证标头中 gas 代付方的签名。
+
+如果两个签名都有效，交易将在用户的授权下执行，但相应的 gas 费用将从 gas 代付方的账户余额中扣除。
+
+### 工作流程图
+
+下图说明了从交易发起 Gas 支付到执行的整个流程：
+
+```d2 Gas 支付工作流 icon=mdi:gas-station
+direction: down
+
+User-App: {
+  label: "用户应用"
+  shape: rectangle
+}
+
+Gas-Payer-Wallet: {
+  label: "Gas 代付方钱包\n(应用后端的钱包)"
+  shape: cylinder
+}
+
+OCAP-Client: {
+  label: "OCAP Client 实例"
+}
+
+Blockchain-Node: {
+  label: "区块链节点"
+  shape: rectangle
+}
+
+User-App -> OCAP-Client: "1. 用户发起交易"
+OCAP-Client -> OCAP-Client: "2. 使用用户钱包\n准备并签署交易"
+Gas-Payer-Wallet -> OCAP-Client: "3. 为 gas 签署交易哈希"
+OCAP-Client -> Blockchain-Node: "4. 发送交易 + Gas 代付方标头"
+Blockchain-Node -> Blockchain-Node: "5. 验证双方签名"
+Blockchain-Node: "6. 执行交易"
+Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 gas 费用"
+```
+
+## 用法示例
+
+要启用无 gas 交易，您只需为代付账户创建一个钱包实例，并使用 `setGasPayer` 方法在客户端上进行设置。
+
+```javascript Gas Payer 设置与使用 icon=logos:javascript
+import Client from '@ocap/client';
+import Wallet, { fromRandom } from '@ocap/wallet';
+
+// 1. 初始化客户端以连接到 Beta 链
+const client = new Client('https://beta.abtnetwork.io/api');
+
+// 2. 为 gas 代付方（您的应用程序的钱包）创建一个钱包
+// 此钱包必须有足够的原生代币（TBA）来支付交易费用。
+// 您可以从水龙头获取测试代币：https://faucet.abtnetwork.io/
+const gasPayerWallet = Wallet.fromJSON({
+  sk: '...your_sponsor_secret_key...',
+  pk: '...your_sponsor_public_key...',
+  address: '...your_sponsor_address...',
+});
+
+// 3. 在客户端实例上设置 gas 代付方
+client.setGasPayer(gasPayerWallet);
+
+// 4. 为最终用户创建一个钱包。
+const userWallet = fromRandom();
+
+// 5. 使用用户的钱包发送一笔交易。
+// 交易由用户签名，但 gas 费用由 gasPayerWallet 支付。
+async function performGaslessTransaction() {
+  try {
+    // 注意：虽然新账户在收到第一笔入账交易时会在链上创建，
+    // 但它必须在链上存在才能 *发送* 交易。
+    // 您可以通过从水龙头向其发送少量代币来初始化它。
+
+    const receiverAddress = 'z1...'; // 一个有效的接收者地址
+    const hash = await client.transfer({
+      to: receiverAddress,
+      tokens: [{ value: '0.1' }], // 发送 0.1 TBA
+      wallet: userWallet,
+    });
+
+    console.log('无 gas 交易成功。哈希:', hash);
+    console.log(`在浏览器上查看: https://beta.abtnetwork.io/explorer/txs/${hash}`);
+  } catch (error) {
+    console.error('交易失败:', error);
+  }
+}
+
+performGaslessTransaction();
+```
+
+在此示例中，`userWallet` 即使原生代币余额为零也能成功发送交易，因为 `gasPayerWallet` 承担了费用。这创造了无摩擦的体验，特别是对于加入您应用程序的新用户而言。
+
+---
+
+要了解从创建到最终确认的完整交易过程，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。

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

@@ -0,0 +1,183 @@
+# トランザクションのライフサイクル
+
+トークンの転送やアセットの作成など、ブロックチェーンの状態を変更するすべてのアクションは、トランザクションを通じて実行されます。トランザクションのライフサイクルを理解することは、OCAP Clientを使用してアプリケーションを構築するための基本です。このプロセスには、準備、エンコード、署名、送信の4つの主要なステージが含まれます。
+
+OCAP Clientは、最大限の制御のためにこれらのステップを個別に実行するか、利便性のためにそれらを組み合わせた高レベルのヘルパーを使用することができる、柔軟なメソッドセットを提供します。
+
+このガイドでは、各ステージを分解し、単一署名と複数署名の両方のワークフローを説明します。
+
+## ライフサイクルの概要
+
+以下の図は、準備からブロックチェーンへの最終的な送信までのトランザクションの完全な流れを示しています。
+
+```d2 Transaction Lifecycle Diagram
+direction: down
+
+Start: {
+  label: "1. Itxの準備"
+  shape: oval
+}
+
+Encode-Tx: {
+  label: "2. トランザクションのエンコード\n(encode<Type>Tx)"
+  shape: rectangle
+}
+
+Sign-Tx: {
+  label: "3. トランザクションの署名"
+  shape: diamond
+}
+
+Single-Sign: {
+  label: "単一署名\n(sign<Type>Tx)"
+  shape: rectangle
+}
+
+Multi-Sign-Flow: {
+  label: "複数署名"
+  shape: rectangle
+  
+  Multi-Sign-1: {
+    label: "署名者1\n(multiSign<Type>Tx)"
+  }
+  
+  Multi-Sign-2: {
+    label: "署名者2\n(multiSign<Type>Tx)"
+  }
+
+  Multi-Sign-N: {
+    label: "..."
+  }
+  
+  Multi-Sign-1 -> Multi-Sign-2: "署名済みTXを渡す"
+  Multi-Sign-2 -> Multi-Sign-N: "署名済みTXを渡す"
+}
+
+Send-Tx: {
+  label: "4. トランザクションの送信\n(send<Type>Tx)"
+  shape: rectangle
+}
+
+End: {
+  label: "トランザクションハッシュ"
+  shape: oval
+}
+
+Start -> Encode-Tx
+Encode-Tx -> Sign-Tx
+Sign-Tx -> Single-Sign: "単一署名者"
+Sign-Tx -> Multi-Sign-Flow: "複数署名者"
+Single-Sign -> Send-Tx
+Multi-Sign-Flow -> Send-Tx
+Send-Tx -> End
+```
+
+## ステージ1：準備（`itx`の作成）
+
+すべてのトランザクションは`itx`（内部トランザクション）から始まります。これは、実行したいアクションの特定のデータを含むプレーンなJavaScriptオブジェクトです。例えば、転送`itx`には受信者のアドレスと金額が含まれます。
+
+```javascript Preparing the itx icon=logos:javascript
+// 転送トランザクションのコアデータ
+const itx = {
+  to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 受信者のアドレス
+  value: await client.fromTokenToUnit(10),   // 送信する量、チェーンの基本単位に変換済み
+};
+```
+
+## ステージ2：エンコード
+
+エンコードは、`itx`と他のメタデータを、暗号学的に署名できる標準化されたバイナリ形式に変換します。クライアントは、各トランザクションタイプに対して`encode{TxType}Tx`メソッド（例：`encodeTransferV2Tx`）を提供します。
+
+このステージで、クライアントは自動的に必須のメタデータを追加します。
+
+*   **`from`**：送信者のアドレス、提供されたウォレットから導出されます。
+*   **`chainId`**：ターゲットブロックチェーンの識別子、自動的に取得されます。
+*   **`nonce`**：リプレイ攻撃を防ぐためのユニークな番号で、デフォルトは現在のタイムスタンプ（`Date.now()`）です。
+*   **`pk`**：送信者のウォレットの公開鍵。
+
+エンコード関数は、完全なトランザクションオブジェクトと、署名に使用されるシリアライズされたデータの`Buffer`の両方を返します。
+
+```javascript Encoding the Transaction icon=logos:javascript
+const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
+  tx: { itx },
+  wallet: senderWallet,
+});
+
+console.log('エンコードされたTXオブジェクト:', encodedTx);
+console.log('署名されるバッファ:', txBuffer);
+```
+
+## ステージ3：署名
+
+署名はアカウントの所有権を証明し、トランザクションを承認します。このプロセスは単一署名と複数署名のワークフローで異なります。
+
+### 単一署名ワークフロー
+
+これは最も一般的なシナリオで、単一のユーザーがトランザクションに署名します。`sign{TxType}Tx`メソッドは、エンコードされたトランザクションを受け取り、ユーザーの秘密鍵でバイナリバッファに署名し、`signature`フィールドに値を設定します。
+
+```javascript Signing with a Single Signature icon=logos:javascript
+const signedTx = await client.signTransferV2Tx({
+  tx: encodedTx, // エンコードステップからのオブジェクト
+  wallet: senderWallet,
+});
+
+console.log('署名:', signedTx.signature);
+```
+
+### 複数署名ワークフロー
+
+複数署名（マルチシグ）トランザクションは、複数の関係者からの承認が必要です。これは一般的にアトミックスワップや共有アカウントで使用されます。プロセスは順次実行されます。
+
+1.  **準備**：初期トランザクションは、必要なすべての署名者を定義する`signaturesList`と共に作成されます。
+2.  **順次署名**：トランザクションは署名者から次の署名者へと渡されます。各署名者は対応する`multiSign{TxType}Tx`メソッドを使用して自身の署名を追加します。
+
+内部的に、`multiSign`メソッドは、署名のためにトランザクションをエンコードする前に既存のすべての署名を一時的に削除することで、各関係者が全く同じトランザクションダイジェストに署名することを保証します。
+
+以下は、二者がアセットを交換する`ExchangeTx`の例です。
+
+```javascript Multi-Signature Signing Example icon=logos:javascript
+// ステップ1：Alice（オファー側）が交換トランザクションを準備し、署名します。
+const txFromAlice = await client.prepareExchange({
+  offerToken: 10,
+  demandToken: 20,
+  receiver: bobWallet.address,
+  wallet: aliceWallet,
+});
+
+// ステップ2：トランザクションがBobに送信されます。
+// Bob（要求側）が署名を追加して最終化します。
+const txFromBob = await client.finalizeExchange({
+  tx: txFromAlice, // Aliceによって署名されたトランザクション
+  wallet: bobWallet,
+});
+
+console.log('Aliceの署名:', txFromBob.signaturesList[0].signature);
+console.log('Bobの署名:', txFromBob.signaturesList[1].signature);
+```
+
+## ステージ4：送信
+
+トランザクションが完全に署名されると、処理のためにブロックチェーンノードに送信できます。`send{TxType}Tx`メソッドがこの最終ステップを処理します。
+
+便宜上、ウォレットと未署名のトランザクションを提供すれば、これらのメソッドは署名ステップを暗黙的に実行することもできます。メソッドは、送信が成功するとトランザクションハッシュで解決されるプロミスを返します。
+
+```javascript Sending the Signed Transaction icon=logos:javascript
+// 事前に署名されたトランザクションを使用
+const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
+
+// または、sendメソッドに署名を自動的に処理させる
+const hash2 = await client.sendTransferV2Tx({
+  tx: { itx }, // 内部トランザクションのみ
+  wallet: senderWallet,
+});
+
+console.log('トランザクション送信完了！ ハッシュ:', hash);
+```
+
+`commit: true`オプションを含めることで、プロミスが解決される前に、トランザクションが完全に確認され、ブロックに含まれるまでクライアントを待機させることもできます。
+
+## まとめ
+
+トランザクションのライフサイクルは、ブロックチェーンと対話するための堅牢で柔軟なフレームワークを提供します。プロセスを準備、エンコード、署名、送信という明確なステージに分けることで、OCAP Clientは開発者にトランザクション作成に対するきめ細かな制御を提供すると同時に、一般的なユースケースのためのシンプルで高レベルなヘルパーも提供します。
+
+トランザクション手数料の処理方法についての詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)ドキュメントを参照してください。

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

@@ -0,0 +1,183 @@
+# Transaction Lifecycle
+
+Every action that modifies the state of the blockchain, such as transferring tokens or creating an asset, is executed through a transaction. Understanding the lifecycle of a transaction is fundamental to building applications with the OCAP Client. This process involves four main stages: Preparation, Encoding, Signing, and Sending.
+
+The OCAP Client provides a flexible set of methods that allow you to either perform these steps individually for maximum control or use high-level helpers that combine them for convenience.
+
+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.
+
+```d2 Transaction Lifecycle Diagram
+direction: down
+
+Start: {
+  label: "1. Prepare Itx"
+  shape: oval
+}
+
+Encode-Tx: {
+  label: "2. Encode Transaction\n(encode<Type>Tx)"
+  shape: rectangle
+}
+
+Sign-Tx: {
+  label: "3. Sign Transaction"
+  shape: diamond
+}
+
+Single-Sign: {
+  label: "Single Signature\n(sign<Type>Tx)"
+  shape: rectangle
+}
+
+Multi-Sign-Flow: {
+  label: "Multi-Signature"
+  shape: rectangle
+  
+  Multi-Sign-1: {
+    label: "Signer 1\n(multiSign<Type>Tx)"
+  }
+  
+  Multi-Sign-2: {
+    label: "Signer 2\n(multiSign<Type>Tx)"
+  }
+
+  Multi-Sign-N: {
+    label: "..."
+  }
+  
+  Multi-Sign-1 -> Multi-Sign-2: "Pass signed TX"
+  Multi-Sign-2 -> Multi-Sign-N: "Pass signed TX"
+}
+
+Send-Tx: {
+  label: "4. Send Transaction\n(send<Type>Tx)"
+  shape: rectangle
+}
+
+End: {
+  label: "Transaction Hash"
+  shape: oval
+}
+
+Start -> Encode-Tx
+Encode-Tx -> Sign-Tx
+Sign-Tx -> Single-Sign: "Single Signer"
+Sign-Tx -> Multi-Sign-Flow: "Multiple Signers"
+Single-Sign -> Send-Tx
+Multi-Sign-Flow -> Send-Tx
+Send-Tx -> 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.
+
+```javascript Preparing the itx icon=logos:javascript
+// The core data for our transfer transaction
+const itx = {
+  to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // Recipient's address
+  value: await client.fromTokenToUnit(10),   // Amount to send, converted to the chain's base unit
+};
+```
+
+## 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.
+
+The encoding function returns both the full transaction object and a `Buffer` of the serialized data, which is used for signing.
+
+```javascript Encoding the Transaction icon=logos:javascript
+const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
+  tx: { itx },
+  wallet: senderWallet,
+});
+
+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.
+
+### Single-Signature Workflow
+
+This is the most common scenario, where a single user signs a transaction. The `sign{TxType}Tx` methods take the encoded transaction, sign the binary buffer with the user's private key, and populate the `signature` field.
+
+```javascript Signing with a Single Signature icon=logos:javascript
+const signedTx = await client.signTransferV2Tx({
+  tx: encodedTx, // The object from the encoding step
+  wallet: senderWallet,
+});
+
+console.log('Signature:', signedTx.signature);
+```
+
+### Multi-Signature Workflow
+
+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.
+
+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.
+
+Here’s an example for an `ExchangeTx`, where two parties swap assets.
+
+```javascript Multi-Signature Signing Example icon=logos:javascript
+// Step 1: Alice (the offerer) prepares and signs the exchange transaction.
+const txFromAlice = await client.prepareExchange({
+  offerToken: 10,
+  demandToken: 20,
+  receiver: bobWallet.address,
+  wallet: aliceWallet,
+});
+
+// Step 2: The transaction is sent to Bob.
+// Bob (the demander) adds his signature to finalize it.
+const txFromBob = await client.finalizeExchange({
+  tx: txFromAlice, // Transaction signed by Alice
+  wallet: bobWallet,
+});
+
+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.
+
+For convenience, these methods can also perform the signing step implicitly if you provide a wallet and an unsigned transaction. The method returns a promise that resolves with the transaction hash upon successful submission.
+
+```javascript Sending the Signed Transaction icon=logos:javascript
+// Using a pre-signed transaction
+const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
+
+// Or, letting the send method handle the signing automatically
+const hash2 = await client.sendTransferV2Tx({
+  tx: { itx }, // Just the inner transaction
+  wallet: senderWallet,
+});
+
+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.