@mysten/docs 0.1.17 → 0.1.19

package/dist/sui/plugins.md

@@ -1,8 +1,8 @@
 # Transaction Plugins
 
-> Extend transaction building with reusable plugins
+> Extend transaction building with reusable plugins.
 
-> **Warning:** The `Transaction` plugin API is experimental and may change rapidly as it is being developed.
+> **Warning:** The `Transaction` plugin API is experimental and might change rapidly as it is being developed.
 
 This document describes the plugin API for the `Transaction` builder. It covers internal details
 intended for developers interested in extending the `Transaction` builder. Developers using the
@@ -19,10 +19,10 @@ modify the data and commands added to a transaction before it is serialized to J
 BCS bytes. Transaction Intents are custom representations of user intents for a transaction,
 eventually resolved to one or more commands in the transaction.
 
-## Contents of a Transaction
+## Contents of a transaction
 
-When a `Transaction` is created (e.g., `new Transaction()`), it is initialized with an empty
-[TransactionDataBuilder](/typedoc/classes/_mysten_sui.transactions.TransactionDataBuilder.html)
+When a `Transaction` is created (for example, `new Transaction()`), it is initialized with an empty
+[`TransactionDataBuilder`](/typedoc/classes/_mysten_sui.transactions.TransactionDataBuilder.html)
 instance which stores the state of the partially built transaction. The full API of the
 `TransactionDataBuilder` won't be covered here, but you can find the available methods and
 properties in the
@@ -35,13 +35,13 @@ takes depend on the command, but they will be one of a few different types:
 - `GasCoin`: A reference to the coin used to pay for gas.
 - `Input`: An input to the transaction (described below).
 - `Result`: The result of a previous command.
-- `NestedResult`: If a previous command returns a tuple (e.g., `SplitCoin`), a `NestedResult` is
-  used to refer to a specific value in that tuple.
+- `NestedResult`: If a previous command returns a tuple (for example, `SplitCoin`), a `NestedResult`
+  is used to refer to a specific value in that tuple.
 
 Transactions also store a list of Inputs, which refer to user-provided values. Inputs can either be
 objects or Pure values and can be represented in several different ways:
 
-- `Pure`: An input value serialized to BCS. Pure values are generally scalar values or simple
+- `Pure`: An input value serialized to BCS. Pure values are generally scalar values or basic
   wrappers like options or vectors and cannot represent object types.
 - `Object`: A fully resolved object reference, which will be one of the following types:
   - `ImmOrOwnedObject`: A reference to an object, including the object's `id`, `version`, and
@@ -52,13 +52,13 @@ objects or Pure values and can be represented in several different ways:
     `digest`.
 - `UnresolvedPure`: A placeholder for a pure value that has not been serialized to BCS.
 - `UnresolvedObject`: A partial reference to an object, often containing just the object's `id`, but
-  may also include a version, digest, or initialSharedVersion.
+  might also include a version, digest, or initialSharedVersion.
 
-## Lifecycle of a Transaction
+## Lifecycle of a transaction
 
 Because transactions can contain `UnresolvedPure` and `UnresolvedObject` inputs, these values need
 to be resolved before the transaction can be serialized to BCS. However, these unresolved inputs can
-be represented in JSON. What may not be able to be represented in JSON are Transaction Intents.
+be represented in JSON. What might not be able to be represented in JSON are Transaction Intents.
 Transaction Intents represent custom concepts added by plugins or third-party SDKs. To account for
 this, the build process of a transaction is split into two phases: serialization and building.
 Serialization prepares the transaction to be serialized to JSON by running serialization plugins,
@@ -66,7 +66,7 @@ and resolving any unsupported intents. The Build phase then runs, which runs bui
 resolves any UnresolvedPure and UnresolvedObject inputs, before the transaction is serialized to
 BCS.
 
-## Serialization Plugins
+## Serialization plugins
 
 Serialization plugins can be added to a `Transaction` by calling the `addSerializationPlugin` method
 on a `Transaction` instance. Serialization plugins are called in the order they are added and are
@@ -82,7 +82,7 @@ transaction.addSerializationPlugin(async (transactionData, buildOptions, next) =
 });
 ```
 
-## Build Plugins
+## Build plugins
 
 The build phase is responsible for taking unresolved objects and unresolved pure values and
 converting them to their resolved versions by querying the RPC API to fetch the missing data. Build
@@ -136,7 +136,7 @@ const transaction = new Transaction();
 transaction.addBuildPlugin(simpleObjectCachePlugin);
 ```
 
-## Transaction Intents
+## Transaction intents
 
 Transaction Intents consist of two parts: adding the intent to the transaction and resolving the
 intent to standard commands.

package/dist/sui/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:
@@ -99,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
 
@@ -179,9 +179,9 @@ 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.
@@ -205,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
@@ -237,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
 
@@ -268,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.
@@ -276,7 +276,7 @@ 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:
 
@@ -293,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 },
@@ -303,7 +303,7 @@ 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:

package/dist/sui/transaction-building/basics.md

@@ -1,6 +1,6 @@
 # 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:
@@ -64,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`
@@ -75,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:
 
@@ -101,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
@@ -140,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
@@ -277,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();

package/dist/sui/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);

package/dist/sui/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
@@ -52,7 +52,7 @@ 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
 

package/dist/sui/transaction-building/offline.md

@@ -1,20 +1,20 @@
 # 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
 
@@ -37,7 +37,7 @@ 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:

package/dist/sui/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.

package/dist/sui/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,7 +14,7 @@ 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
+> **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.
 
@@ -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,
+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/dist/sui/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.
@@ -31,6 +31,13 @@ You can use the following helpers to format various values:
 - `normalizeSuiNSName`
 - `normalizeSuiNSName`
 
+## Parsers
+
+You can use the following helpers to parse decimal strings into smallest-unit bigints:
+
+- `parseToUnits`: Parse a decimal string into a `bigint`, given a coin's `decimals`
+- `parseToMist`: Parse a SUI decimal string into MIST (9 decimals)
+
 ## Validators
 
 You can use the following helpers to validate the format of various values (this only validates that

package/dist/sui/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.

package/dist/walrus/index.md

@@ -1,6 +1,6 @@
 # Walrus SDK
 
-> Store and retrieve blobs on Walrus decentralized storage
+> Store and retrieve blobs on Walrus decentralized storage using the TypeScript SDK.
 
 The Walrus TypeScript SDK works directly with Walrus storage nodes or with the Walrus upload relay.
 When you use the Walrus SDK without an upload relay, reading and writing Walrus blobs requires many

package/dist/walrus/llms-index.md

@@ -1,4 +1,4 @@
 # Walrus
 > Publish and Read blobs directly from walrus storage nodes
 
-- [Walrus SDK](..md): Store and retrieve blobs on Walrus decentralized storage
+- [Walrus SDK](..md): Store and retrieve blobs on Walrus decentralized storage using the TypeScript SDK.

package/dist/zksend/composable-claim.md

@@ -0,0 +1,70 @@
+# Composable Claims
+
+> Claim a zkSend link and use the assets in the same transaction
+
+By default, `link.claimAssets(address)` builds a claim transaction that transfers every asset to the
+recipient and submits it via a Mysten-hosted sponsor. If you want to _use_ a claimed object in the
+same transaction — for example, inserting a claimed NFT into another on-chain object, staking a
+claimed coin, or depositing into a vault — use `link.claimFlow()` to compose the claim into your own
+transaction.
+
+## How it works
+
+`link.claimFlow()` returns three transaction thunks:
+
+- **`init`** — adds the `init_claim` (or `reclaim`) move call that creates the claim proof.
+- **`assets`** — an array of claimable assets. Each `asset.argument` is a lazy
+  `TransactionObjectArgument` that emits the backing `claim<T>` move call the first time it's used.
+- **`finalize`** — consumes the claim proof. Must be added after every asset is claimed.
+
+```ts
+
+const tx = new Transaction();
+tx.setSender(claimLink.keypair!.toSuiAddress());
+
+const { init, assets, finalize } = claimLink.claimFlow();
+
+tx.add(init);
+
+for (const asset of assets) {
+	if (asset.type === `${PACKAGE_ID}::record::Record`) {
+		// Insert the claimed record directly into the recipient's player object
+		tx.moveCall({
+			target: `${PACKAGE_ID}::player::add_record`,
+			arguments: [tx.object(playerId), asset.argument],
+		});
+	} else {
+		tx.transferObjects([asset.argument], recipient);
+	}
+}
+
+tx.add(finalize);
+```
+
+Every asset in the returned list must be claimed somewhere in the transaction — assets that are
+never used won't create a `claim<T>` command and the transaction will fail. If you only want the
+default claim-and-transfer behavior, use `link.createClaimTransaction(address)` instead.
+
+## Sponsorship
+
+`link.claimAssets(address)` uses a sponsorship flow so the claimer does not need gas to claim the
+assets, but it only accepts the standard `init_claim` → `claim<T>` → transfer → `finalize` shape.
+Transactions built with `claimFlow()` may include extra move calls, so the default sponsor may
+reject them.
+
+Apps using `claimFlow()` are responsible for their own gas and sponsorship. The ephemeral link
+keypair is still the transaction sender (it authorizes the claim), so the typical pattern is dual
+signing: the link keypair signs as sender and your app's sponsor signs for gas.
+
+```ts
+tx.setGasOwner(sponsorAddress);
+const txBytes = await tx.build({ client });
+
+const linkSig = await claimLink.keypair!.signTransaction(txBytes);
+const sponsorSig = await sponsor.signTransaction(txBytes);
+
+const result = await client.core.executeTransaction({
+	transaction: txBytes,
+	signatures: [linkSig.signature, sponsorSig.signature],
+});
+```

package/dist/zksend/index.md

@@ -1,6 +1,6 @@
 # zkSend SDK
 
-> Send Sui assets via shareable links with zkSend
+> Send Sui assets through shareable claim links using the zkSend SDK.
 
 The zkSend SDK provides tools for interacting with the zkSend primitive. It provides functionality
 to create your own zkSend Claim Links, with support for any publicly transferrable asset.
@@ -23,5 +23,5 @@ const client = new SuiGrpcClient({
 }).$extend(zksend());
 ```
 
-The zkSend SDK supports mainnet and testnet networks. The extension automatically configures the
+The zkSend SDK supports Mainnet and Testnet networks. The extension automatically configures the
 correct contract IDs based on the client's network.

package/dist/zksend/link-builder.md

@@ -1,8 +1,8 @@
 # Creating zkSend Links
 
-> Create and customize zkSend claim links
+> Create and customize zkSend claim links for sending Sui assets.
 
-> **Warning:** Products and services that incorporate zkSend links may be subject to financial regulations,
+> **Warning:** Products and services that incorporate zkSend links might be subject to financial regulations,
 > including obtaining money transmitter licenses in jurisdictions where you provide your services.
 > It is the developer's responsibility to ensure compliance with all relevant laws and obtain any
 > necessary licenses. The information provided by Mysten Labs is not legal advice, and developers
@@ -42,7 +42,8 @@ params:
 You can add non-SUI coins to the link by calling `link.addClaimableBalance()`. This method takes the
 following params:
 
-- **`coinType`** (required) - The coin type of the coin to add to the link (e.g. `0x2::sui::SUI`).
+- **`coinType`** (required) - The coin type of the coin to add to the link (for example,
+  `0x2::sui::SUI`).
 - **`amount`** (required) - The amount of the coin to add to the link. Represented in the base unit
   of the coin.
 
@@ -124,7 +125,7 @@ await link.create({
 
 ## Claiming a link
 
-To claim a link via the SDK you can use the `loadLinkFromUrl` method:
+To claim a link through the SDK you can use the `loadLinkFromUrl` method:
 
 ```ts
 // Load a link instance from a URL

package/dist/zksend/llms-index.md

@@ -1,5 +1,6 @@
 # ZkSend
 > Send Sui with a link
 
-- [zkSend SDK](..md): Send Sui assets via shareable links with zkSend
-- [Creating zkSend Links](./link-builder.md): Create and customize zkSend claim links
+- [zkSend SDK](..md): Send Sui assets through shareable claim links using the zkSend SDK.
+- [Creating zkSend Links](./link-builder.md): Create and customize zkSend claim links for sending Sui assets.
+- [Composable Claims](./composable-claim.md): Claim a zkSend link and use the assets in the same transaction