@mysten/sui 2.16.0 → 2.16.2

package/docs/sdk-building.md

@@ -1,22 +1,22 @@
 # Building SDKs
 
-> Build custom SDKs on top of the Sui TypeScript SDK
+> Build custom SDKs on top of the Sui TypeScript SDK.
 
 This guide covers recommended patterns for building TypeScript SDKs that integrate with the Sui SDK.
 Following these patterns ensures your SDK integrates seamlessly with the ecosystem, works across
 different transports (JSON-RPC, GraphQL, gRPC), and composes well with other SDKs.
 
-**Key requirement:** All SDKs should depend on [`ClientWithCoreApi`](./clients/core), which is the
-transport-agnostic interface implemented by all Sui clients. This ensures your SDK works with any
-client the user chooses.
+All SDKs should depend on [`ClientWithCoreApi`](./clients/core), which is the transport-agnostic
+interface implemented by all Sui clients. This ensures your SDK works with any client the user
+chooses.
 
-## Package Setup
+## Package setup
 
-### Use Mysten Packages as Peer Dependencies
+### Use Mysten packages as peer dependencies
 
-SDKs should declare all `@mysten/*` packages as **peer dependencies** rather than direct
-dependencies. This ensures users get a single shared instance of each package, avoiding version
-conflicts and duplicate code.
+SDKs should declare all `@mysten/*` packages as peer dependencies rather than direct dependencies.
+This ensures users get a single shared instance of each package, avoiding version conflicts and
+duplicate code.
 
 ```json title="package.json"
 {
@@ -40,14 +40,14 @@ This approach:
 - Avoids subtle bugs from mismatched package instances
 - Allows the SDK to work with any compatible client
 
-## Client Extensions
+## Client extensions
 
 The recommended way to build SDKs is using the **client extension pattern**. This allows your SDK to
 extend the Sui client with custom functionality. This makes it easier to use custom SDKs across the
 ecosystem without having to build custom bindings (like react context providers) for each individual
 SDK and client.
 
-### Extension Pattern
+### Extension pattern
 
 Client extensions use the `$extend` method to add functionality to any Sui client. Create a factory
 function that returns a `name` and `register` function:
@@ -89,6 +89,7 @@ function that returns a `name` and `register` function:
 Users can then extend their client:
 
 ```typescript
+
 const client = new SuiGrpcClient({
 	network: 'testnet',
 	baseUrl: 'https://fullnode.testnet.sui.io:443',
@@ -98,25 +99,25 @@ const client = new SuiGrpcClient({
 await client.mySDK.getResource('0x...');
 ```
 
-### Real-World Examples
+### Real-world examples
 
 Several official SDKs use this pattern:
 
-- **[@mysten/walrus](https://www.npmjs.com/package/@mysten/walrus)** - Decentralized storage
-- **[@mysten/seal](https://www.npmjs.com/package/@mysten/seal)** - Encryption and key management
+- **[@mysten/walrus](https://www.npmjs.com/package/@mysten/walrus):** Decentralized storage
+- **[@mysten/seal](https://www.npmjs.com/package/@mysten/seal):** Encryption and key management
 
-## SDK Organization
+## SDK organization
 
 Most Mysten SDKs do not strictly follow these patterns yet, but we recommend scoping methods on your
 client extension into the following categories for clarity and consistency:
 
-| Property | Purpose                                                   | Example                             |
-| -------- | --------------------------------------------------------- | ----------------------------------- |
-| Methods  | Top-level operations (execute actions or read/parse data) | `sdk.readBlob()`, `sdk.getConfig()` |
-| `tx`     | Methods that create transactions without executing        | `sdk.tx.registerBlob()`             |
-| `bcs`    | BCS type definitions for encoding/decoding                | `sdk.bcs.MyStruct`                  |
-| `call`   | Methods returning Move calls that can be used with tx.add | `sdk.call.myFunction()`             |
-| `view`   | Methods that use simulate API to read onchain state       | `sdk.view.getState()`               |
+| Property | Purpose                                                       | Example                             |
+| -------- | ------------------------------------------------------------- | ----------------------------------- |
+| Methods  | Top-level operations (execute actions or read and parse data) | `sdk.readBlob()`, `sdk.getConfig()` |
+| `tx`     | Methods that create transactions without executing            | `sdk.tx.registerBlob()`             |
+| `bcs`    | BCS type definitions for encoding and decoding                | `sdk.bcs.MyStruct`                  |
+| `call`   | Methods returning Move calls that can be used with tx.add     | `sdk.call.myFunction()`             |
+| `view`   | Methods that use simulate API to read onchain state           | `sdk.view.getState()`               |
 
 ```typescript
 
@@ -178,14 +179,15 @@ client extension into the following categories for clarity and consistency:
 }
 ```
 
-## Transaction Building Patterns
+## Transaction building patterns
 
-### Transaction Thunks
+### Transaction thunks
 
 Transaction thunks are functions that accept a `Transaction` and mutate it. This pattern enables
 composition across multiple SDKs in a single transaction.
 
 ```typescript
+
 // Synchronous thunk for operations that don't need async work
 function createResource(options: { name: string }) {
 	return (tx: Transaction): TransactionObjectArgument => {
@@ -203,7 +205,7 @@ const resource = tx.add(createResource({ name: 'my-resource' }));
 tx.transferObjects([resource], recipient);
 ```
 
-### Async Thunks
+### Async thunks
 
 For operations requiring async work (like fetching package IDs or configuration), return async
 thunks. These are used with `tx.add()` exactly like synchronous thunks - the async resolution
@@ -235,14 +237,14 @@ await signer.signAndExecuteTransaction({ transaction: tx, client });
 This pattern is critical for web wallet compatibility - async work that happens during transaction
 construction won't block the popup triggered by user interaction.
 
-## Transaction Execution
+## Transaction execution
 
-### Accept a Signer Parameter
+### Accept a signer parameter
 
 For methods that execute transactions, accept a `Signer` parameter and always use the signer to
 execute the transaction. This enables:
 
-- Wallet integration through dApp Kit
+- Wallet integration through dApp kit
 - Transaction sponsorship
 - Custom signing flows
 
@@ -266,7 +268,7 @@ execute the transaction. This enables:
 
 Using `signAndExecuteTransaction` allows wallets and sponsors to customize execution behavior.
 
-## Code Generation
+## Code generation
 
 For SDKs that interact with Move contracts, use **[@mysten/codegen](/codegen)** to generate
 type-safe TypeScript bindings from your Move packages.
@@ -274,11 +276,12 @@ type-safe TypeScript bindings from your Move packages.
 Benefits include type safety, BCS parsing, IDE support, and MoveRegistry support for human-readable
 package names. See the [codegen documentation](/codegen) for setup instructions.
 
-### Using Generated Code
+### Using generated code
 
 The generated code provides both Move call functions and BCS struct definitions:
 
 ```typescript
+
 // Generated Move call functions return thunks with typed options
 const tx = new Transaction();
 tx.add(
@@ -290,7 +293,7 @@ tx.add(
 	}),
 );
 
-// Generated BCS types parse on-chain data
+// Generated BCS types parse onchain data
 const { object } = await client.core.getObject({
 	objectId: '0x123...',
 	include: { content: true },
@@ -300,12 +303,13 @@ const parsed = myContract.MyStruct.parse(object.content);
 
 See the [codegen documentation](/codegen) for complete setup and configuration options.
 
-## Reading Object Contents
+## Reading object contents
 
 SDKs often need to fetch objects and parse their BCS-encoded content. Use `getObject` with
 `include: { content: true }` and generated BCS types:
 
 ```typescript
+
 async function getResource(objectId: string) {
 	const { object } = await this.#client.core.getObject({
 		objectId,
@@ -337,4 +341,4 @@ async function getResources(objectIds: string[]) {
 		return MyStruct.parse(obj.content);
 	});
 }
-```
+```

package/docs/transaction-building/basics.md

@@ -1,11 +1,12 @@
 # Sui Programmable Transaction Basics
 
-> Construct programmable transaction blocks with the Transaction API
+> Construct programmable transaction blocks with the Transaction API.
 
 This example starts by constructing a transaction to send SUI. To construct transactions, import the
 `Transaction` class and construct it:
 
 ```tsx
+
 const tx = new Transaction();
 ```
 
@@ -63,7 +64,7 @@ if (result.$kind === 'FailedTransaction') {
 
 When you use `client.signAndExecuteTransaction` or `client.executeTransactionBlock`, the transaction
 will be finalized on the blockchain before the function resolves, but the effects of the transaction
-may not be immediately observable.
+might not be immediately observable.
 
 There are 2 ways to observe the results of a transaction. Methods like
 `client.signAndExecuteTransaction` accept an `options` object with options like `showObjectChanges`
@@ -74,7 +75,7 @@ immediately displayed to the user, or used for further processing in your applic
 
 The other way effects of transactions can be observed is by querying other RPC methods like
 `client.getBalances` that return objects or balances owned by a specific address. These RPC calls
-depend on the RPC node having indexed the effects of the transaction, which may not have happened
+depend on the RPC node having indexed the effects of the transaction, which might not have happened
 immediately after a transaction has been executed. To ensure that effects of a transaction are
 represented in future RPC calls, you can use the `waitForTransaction` method on the client:
 
@@ -100,21 +101,21 @@ Commands are steps of execution in the transaction. Each command in a Transactio
 inputs, and produces results. The inputs for a transaction depend on the kind of command. Sui
 supports following commands:
 
-- `tx.splitCoins(coin, amounts)` - Creates new coins with the defined amounts, split from the
+- `tx.splitCoins(coin, amounts)`: Creates new coins with the defined amounts, split from the
   provided coin. Returns the coins so that it can be used in subsequent transactions.
   - Example: `tx.splitCoins(tx.gas, [100, 200])`
-- `tx.mergeCoins(destinationCoin, sourceCoins)` - Merges the sourceCoins into the destinationCoin.
+- `tx.mergeCoins(destinationCoin, sourceCoins)`: Merges the sourceCoins into the destinationCoin.
   - Example: `tx.mergeCoins(tx.object(coin1), [tx.object(coin2), tx.object(coin3)])`
-- `tx.transferObjects(objects, address)` - Transfers a list of objects to the specified address.
+- `tx.transferObjects(objects, address)`: Transfers a list of objects to the specified address.
   - Example: `tx.transferObjects([tx.object(thing1), tx.object(thing2)], myAddress)`
-- `tx.moveCall({ target, arguments, typeArguments  })` - Executes a Move call. Returns whatever the
+- `tx.moveCall({ target, arguments, typeArguments  })`: Executes a Move call. Returns whatever the
   Sui Move call returns.
   - Example:
     `tx.moveCall({ target: '0x2::devnet_nft::mint', arguments: [tx.pure.string(name), tx.pure.string(description), tx.pure.string(image)] })`
-- `tx.makeMoveVec({ type, elements })` - Constructs a vector of objects that can be passed into a
+- `tx.makeMoveVec({ type, elements })`: Constructs a vector of objects that can be passed into a
   `moveCall`. This is required as there’s no way to define a vector as an input.
   - Example: `tx.makeMoveVec({ elements: [tx.object(id1), tx.object(id2)] })`
-- `tx.publish(modules, dependencies)` - Publishes a Move package. Returns the upgrade capability
+- `tx.publish(modules, dependencies)`: Publishes a Move package. Returns the upgrade capability
   object.
 
 ## Passing inputs to a command
@@ -139,7 +140,7 @@ tx.transferObjects([coin], '0xSomeSuiAddress');
 
 When providing inputs that are not on chain objects, the values must be serialized as
 
-[BCS](https://sdk.mystenlabs.com/bcs), which can be done using `tx.pure` eg,
+[BCS](https://sdk.mystenlabs.com/bcs), which can be done using `tx.pure`, for example
 `tx.pure.address(address)` or `tx.pure(bcs.vector(bcs.U8).serialize(bytes))`.
 
 `tx.pure` can be called as a function that accepts a SerializedBcs object, or as a namespace that
@@ -157,6 +158,7 @@ tx.pure as a function with a type argument, or serialize the value before passin
 using the bcs sdk:
 
 ```ts
+
 tx.moveCall({
 	target: '0x2::foo::bar',
 	arguments: [
@@ -275,9 +277,9 @@ tx.transferObjects([mintMany[0], mintMany[1]], address);
 If you need the transaction bytes, instead of signing or executing the transaction, you can use the
 `build` method on the transaction builder itself.
 
-**Important:** You might need to explicitly call `setSender()` on the transaction to ensure that the
-`sender` field is populated. This is normally done by the signer before signing the transaction, but
-will not be done automatically if you’re building the transaction bytes yourself.
+You might need to explicitly call `setSender()` on the transaction to ensure that the `sender` field
+is populated. This is normally done by the signer before signing the transaction, but will not be
+done automatically if you’re building the transaction bytes yourself.
 
 ```tsx
 const tx = new Transaction();
@@ -294,4 +296,4 @@ If you have transaction bytes, you can also convert them back into a `Transactio
 ```tsx
 const bytes = getTransactionBytesFromSomewhere();
 const tx = Transaction.from(bytes);
-```
+```

package/docs/transaction-building/gas.md

@@ -1,6 +1,6 @@
 # Paying for Sui Transactions with Gas Coins
 
-> Configure gas budget, price, and coin selection for transactions
+> Configure gas budget, price, and coin selection for Sui transactions.
 
 With Programmable Transactions, you can use the gas payment coin to construct coins with a set
 balance using `splitCoin`. This is useful for Sui payments, and avoids the need for up-front coin
@@ -35,8 +35,7 @@ beforehand. The dry run gas consumption is then used to determine a balance for
 can override this behavior by explicitly setting a gas budget for the transaction, by calling
 `setGasBudget` on the transaction builder.
 
-**Note:** The gas budget is represented in Sui, and should take the gas price of the transaction
-into account.
+The gas budget is represented in Sui and should take the gas price of the transaction into account.
 
 ```tsx
 tx.setGasBudget(gasBudgetAmount);
@@ -59,4 +58,4 @@ tx.setGasPayment([coin1, coin2]);
 
 Gas coins should be objects containing the coins objectId, version, and digest.
 
-<auto-type-table type="{ objectId: string, version: string | number, digest: string }" />
+<auto-type-table type="{ objectId: string, version: string | number, digest: string }" />

package/docs/transaction-building/intents.md

@@ -1,9 +1,9 @@
 # Transaction Intents
 
-> Use high-level intents to simplify transaction building
+> Use high-level intents to simplify transaction building.
 
-Transaction Intents enable 3rd party SDKs and [Transaction Plugins](../plugins) to more easily add
-complex operations to a Transaction. The Typescript SDK currently only includes a single Intent
+Transaction Intents enable third-party SDKs and [Transaction Plugins](../plugins) to more easily add
+operations to a Transaction. The TypeScript SDK currently only includes a single Intent
 (CoinWithBalance), but more will be added in the future.
 
 ## The CoinWithBalance intent
@@ -24,6 +24,7 @@ solves this by providing a helper function that automatically adds the correct S
 MergeCoins commands to the transaction:
 
 ```typescript
+
 const tx = new Transaction();
 
 // Setting the sender is required for the CoinWithBalance intent to resolve coins when not using the gas coin
@@ -51,11 +52,11 @@ tx.transferObjects([coinWithBalance({ balance: 100, useGasCoin: false })], recip
 ```
 
 It's important to only set `useGasCoin` option to false for sponsored transactions, otherwise the
-coinWithBalance intent may use all the SUI coins, leaving no coins to use for gas.
+coinWithBalance intent might use all the SUI coins, leaving no coins to use for gas.
 
 ## How it works
 
 When the `CoinWithBalance` intent is resolved, it will look up the senders owned coins for each type
 that needs to be created. It will then find a set of coins with sufficient balance to cover the
 desired balance, to combine them into a single coin. This coin is then used in a `SplitCoins`
-command to create the desired coin.
+command to create the desired coin.

package/docs/transaction-building/offline.md

@@ -1,22 +1,23 @@
 # Building Offline
 
-> Build transactions without a network connection
+> Build transactions without a network connection.
 
 To build a transaction offline (with no `client` required), you need to fully define all of your
 inputs, gas configuration, and expiration.
 
-## Required Configuration
+## Required configuration
 
 When building offline, you must set the following:
 
-- **Sender address** - The address that will execute the transaction
-- **Gas price** - The price per gas unit (can be obtained from the network beforehand)
-- **Gas budget** - The maximum gas to spend on this transaction
-- **Gas payment** - One or more coin object references to use for gas, or an empty array for Address
+- Sender address: The address that will execute the transaction
+- Gas price: The price per gas unit (can be obtained from the network beforehand)
+- Gas budget: The maximum gas to spend on this transaction
+- Gas payment: One or more coin object references to use for gas, or an empty array for Address
   Balances
-- **Expiration** - Only needed when using address balances for gas
+- Expiration: Only needed when using address balances for gas
 
 ```tsx
+
 const { referenceGasPrice } = await client.getReferenceGasPrice();
 
 const tx = new Transaction();
@@ -36,12 +37,13 @@ tx.setGasPayment([
 const bytes = await tx.build();
 ```
 
-## Object References
+## Object references
 
 For objects used in your transaction, you must provide full object references using the `Inputs`
 helper:
 
 ```tsx
+
 // For owned or immutable objects
 tx.object(
 	Inputs.ObjectRef({
@@ -68,4 +70,4 @@ tx.object(
 		digest: '<object-digest>',
 	}),
 );
-```
+```

package/docs/transaction-building/sponsored-transactions.md

@@ -1,6 +1,6 @@
 # Sponsored Transactions
 
-> Pay gas fees on behalf of other users with sponsored transactions
+> Pay gas fees on behalf of other users with sponsored transactions.
 
 The transaction builder can support sponsored transactions by using the `onlyTransactionKind` flag
 when building the transaction.
@@ -19,4 +19,4 @@ const sponsoredtx = Transaction.fromKind(kindBytes);
 sponsoredtx.setSender(sender);
 sponsoredtx.setGasOwner(sponsor);
 sponsoredtx.setGasPayment(sponsorCoins);
-```
+```

package/docs/utils/derived_objects.md

@@ -1,6 +1,6 @@
 # Derived Objects
 
-> Compute derived object IDs from parent objects
+> Compute derived object IDs from parent objects for deterministic offline derivation.
 
 Derived objects enable deterministic IDs for objects, enabling offline derivation of object IDs.
 [Click here to read more.](https://docs.sui.io/concepts/sui-move-concepts/derived-objects)
@@ -14,9 +14,9 @@ To derive an object ID, you can import `deriveObjectID` function exposed from ut
 To derive any object, you need to have its parent's ID (the object from which it was derived), and
 the key used to generate it.
 
-> **Warning:** It is recommended to verify the on-chain `derived_object::derive_address` match your
-> off-chain calculation (at least once when implementing offline calculations), especially for
-> critical cases like transferring assets.
+> **Warning:** It is recommended to verify the onchain `derived_object::derive_address` match your offchain
+> calculation (at least once when implementing offline calculations), especially for critical cases
+> like transferring assets.
 
 ## Deriving using primitive keys
 
@@ -24,21 +24,21 @@ To derive the IDs using primitive types, you can use the built-in types like thi
 a parent object with ID `0xc0ffee`.
 
 ```typescript
-// Example 1: On-chain derivation for `0xc0ffee + vector<u8>([0,1,2])
+// Example 1: Onchain derivation for `0xc0ffee + vector<u8>([0,1,2])
 deriveObjectID('0xc0ffee', 'vector<u8>', bcs.vector(bcs.u8()).serialize([0, 1, 2]).toBytes());
 
-// Example 2: On-chain derivation for `0xc0ffee + address('0x111')`
+// Example 2: Onchain derivation for `0xc0ffee + address('0x111')`
 deriveObjectID('0xc0ffee', 'address', bcs.Address.serialize('0x111').toBytes());
 
-// Example 3: On-chain derivation for `0xc0ffee + non-ascii string ("foo")`
+// Example 3: Onchain derivation for `0xc0ffee + non-ascii string ("foo")`
 deriveObjectID('0xc0ffee', '0x1::string::String', bcs.String.serialize('foo').toBytes());
 ```
 
 ## Deriving using custom types
 
-To derive IDs using your custom objects, you can use BCS & the known type IDs.
+To derive IDs using your custom objects, you can use BCS and the known type IDs.
 
-Assuming a custom struct on-chain (for the key) being:
+Assuming a custom struct onchain (for the key) being:
 
 ```move
 public struct DemoStruct has copy, store, drop { value: u64 }
@@ -61,14 +61,14 @@ deriveObjectID('0xc0ffee', `0xc0ffee::demo::DemoStruct`, key);
 ### Deriving with fieldless structs
 
 In Move, structs with no user-defined fields automatically get a `dummy_field: bool` injected by the
-compiler. This means their BCS encoding is not empty — it's a single `0x00` byte (the encoding of
+compiler. This means their BCS encoding is not empty. It is a single `0x00` byte (the encoding of
 `false`). You can treat this as a constant.
 
 A real-world example is `0x2::coin_registry::CurrencyKey<T>`, which is a fieldless generic struct
 used to derive `Currency` objects from the coin registry (`0xc`) based on their type:
 
 ```typescript
-// On-chain: `public struct CurrencyKey<phantom T>() has copy, store, drop`
+// Onchain: `public struct CurrencyKey<phantom T>() has copy, store, drop`
 // The compiler injects `dummy_field: bool`, always `false`.
 const key = new Uint8Array([0]);
 
@@ -76,5 +76,5 @@ const coinType = '0x2::sui::SUI';
 const currencyId = deriveObjectID('0xc', `0x2::coin_registry::CurrencyKey<${coinType}>`, key);
 ```
 
-This applies to any struct with no fields — phantom type parameters don't add any BCS-encoded data,
-so the key is always `new Uint8Array([0])`.
+This applies to any struct with no fields. Phantom type parameters do not add any BCS-encoded data,
+so the key is always `new Uint8Array([0])`.

package/docs/utils/index.md

@@ -1,6 +1,6 @@
 # The `@mysten/sui/utils` package
 
-> Utility functions for addresses, coins, and common operations
+> Utility functions for addresses, coins, and common operations in the Sui TypeScript SDK.
 
 This package contains some utilities that simplify common operations when working with the Sui
 TypeScript SDK.
@@ -56,4 +56,4 @@ The following methods are re-exported to help with converting between commonly u
 - `fromHex`: Deserializes a hex string to a Uint8Array
 - `toHex`: Serializes a Uint8Array to a hex string
 - `fromBase64`: Deserializes a base64 string to a Uint8Array
-- `toBase64`: Serializes a Uint8Array to a base64 string
+- `toBase64`: Serializes a Uint8Array to a base64 string

package/docs/zklogin.md

@@ -1,6 +1,6 @@
 # ZkLogin
 
-> Zero-knowledge authentication with OAuth providers on Sui
+> Zero-knowledge authentication with OAuth providers on Sui.
 
 Utilities for working with zkLogin. Currently contains functionality to create and parse zkLogin
 signatures and compute zkLogin addresses.
@@ -8,30 +8,35 @@ signatures and compute zkLogin addresses.
 To parse a serialized zkLogin signature
 
 ```typescript
+
 const parsedSignature = await parseZkLoginSignature('BQNNMTY4NjAxMzAyO....');
 ```
 
 Use `getZkLoginSignature` to serialize a zkLogin signature.
 
 ```typescript
+
 const serializedSignature = await getZkLoginSignature({ inputs, maxEpoch, userSignature });
 ```
 
 To compute the address for a given address seed and iss you can use `computeZkLoginAddressFromSeed`
 
 ```typescript
+
 const address = computeZkLoginAddressFromSeed(0n, 'https://accounts.google.com');
 ```
 
 To compute an address from jwt:
 
 ```typescript
+
 const address = jwtToAddress(jwtAsString, salt);
 ```
 
 To compute an address from a parsed jwt:
 
 ```typescript
+
 const address = computeZkLoginAddress({
 	claimName,
 	claimValue,
@@ -75,4 +80,4 @@ const address = toZkLoginPublicIdentifier(
 	iss,
 	{ legacyAddress: true },
 ).toSuiAddress();
-```
+```

package/package.json

@@ -3,7 +3,7 @@
   "author": "Mysten Labs <build@mystenlabs.com>",
   "description": "Sui TypeScript API",
   "homepage": "https://sdk.mystenlabs.com",
-  "version": "2.16.0",
+  "version": "2.16.2",
   "license": "Apache-2.0",
   "sideEffects": false,
   "files": [
@@ -139,7 +139,6 @@
     "@graphql-codegen/typescript-document-nodes": "5.0.7",
     "@graphql-codegen/typescript-operations": "^5.0.7",
     "@grpc/grpc-js": "^1.13.3",
-    "@iarna/toml": "^2.2.5",
     "@parcel/watcher": "^2.5.4",
     "@protobuf-ts/grpc-transport": "^2.11.1",
     "@types/node": "^25.0.8",
@@ -169,8 +168,8 @@
     "graphql": "^16.12.0",
     "poseidon-lite": "0.2.1",
     "valibot": "^1.2.0",
-    "@mysten/bcs": "^2.0.3",
-    "@mysten/utils": "^0.3.1"
+    "@mysten/bcs": "^2.0.5",
+    "@mysten/utils": "^0.3.3"
   },
   "scripts": {
     "clean": "rm -rf tsconfig.tsbuildinfo ./dist",
@@ -183,7 +182,7 @@
     "codegen:grpc-header": "find src/grpc/proto -type f -exec sh -c 'echo \"// Copyright (c) Mysten Labs, Inc.\\n// SPDX-License-Identifier: Apache-2.0\\n\" | cat - {} > temp && mv temp {}' \\;",
     "codegen:grpc-extensions": "find src/grpc/proto -name '*.ts' | xargs sed -i '' -E 's/from \"(\\.[^\"]+)\"/from \"\\1.js\"/g'",
     "build": "rm -rf dist && node genversion.mjs && tsc --noEmit && tsdown",
-    "build:docs": "tsx ../docs/scripts/build-docs.ts",
+    "build:docs": "node ../docs/scripts/build-docs.ts",
     "vitest": "vitest",
     "test": "pnpm test:typecheck && pnpm test:unit",
     "test:typecheck": "tsc -p ./test",

package/src/jsonRpc/http-transport.ts

@@ -1,7 +1,7 @@
 // Copyright (c) Mysten Labs, Inc.
 // SPDX-License-Identifier: Apache-2.0
 
-import { PACKAGE_VERSION, TARGETED_RPC_VERSION } from '../version.js';
+import { PACKAGE_VERSION } from '../version.js';
 import { JsonRpcError, SuiHTTPStatusError } from './errors.js';
 
 /**
@@ -58,7 +58,6 @@ export class JsonRpcHTTPTransport implements JsonRpcTransport {
 				'Content-Type': 'application/json',
 				'Client-Sdk-Type': 'typescript',
 				'Client-Sdk-Version': PACKAGE_VERSION,
-				'Client-Target-Api-Version': TARGETED_RPC_VERSION,
 				'Client-Request-Method': input.method,
 				...this.#options.rpc?.headers,
 			},

package/src/version.ts

@@ -3,5 +3,4 @@
 
 // This file is generated by genversion.mjs. Do not edit it directly.
 
-export const PACKAGE_VERSION = '2.16.0';
-export const TARGETED_RPC_VERSION = '1.71.0';
+export const PACKAGE_VERSION = '2.16.2';