@mysten/docs 0.1.44 → 0.1.46

package/dist/codegen/index.md

@@ -67,15 +67,16 @@ This generates TypeScript code in your configured output directory (for example,
 
 The `SuiCodegenConfig` type supports the following options:
 
-| Option                         | Type                   | Default | Description                                                                                                                                                           |
-| ------------------------------ | ---------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `output`                       | `string`               | -       | The directory where generated code will be written                                                                                                                    |
-| `packages`                     | `PackageConfig[]`      | -       | Array of Move packages to generate code for                                                                                                                           |
-| `prune`                        | `boolean`              | `true`  | When enabled, only generates code for the main package and omits dependency modules (dependency types referenced by included types are still generated under `deps/`) |
-| `generateSummaries`            | `boolean`              | `true`  | Automatically run `sui move summary` before generating code. Creates a `package_summaries` directory in your Move package which can be added to `.gitignore`          |
-| `generate`                     | `GenerateOptions`      | -       | Default [generate options](#the-generate-option) (types, functions) for all packages                                                                                  |
-| `importExtension`              | `'.js' \| '.ts' \| ''` | `'.js'` | File extension used in generated import statements                                                                                                                    |
-| `includePhantomTypeParameters` | `boolean`              | `false` | Include [phantom type parameters](#phantom-types) as function arguments in generated BCS types                                                                        |
+| Option                         | Type                   | Default              | Description                                                                                                                                                           |
+| ------------------------------ | ---------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `output`                       | `string`               | -                    | The directory where codegen writes generated code                                                                                                                     |
+| `packages`                     | `PackageConfig[]`      | -                    | Array of Move packages to generate code for                                                                                                                           |
+| `prune`                        | `boolean`              | `true`               | When enabled, only generates code for the main package and omits dependency modules (dependency types referenced by included types are still generated under `deps/`) |
+| `generateSummaries`            | `boolean`              | `true`               | Automatically run `sui move summary` before generating code. Creates a `package_summaries` directory in your Move package which can be added to `.gitignore`          |
+| `generate`                     | `GenerateOptions`      | -                    | Default [generate options](#the-generate-option) (types, functions) for all packages                                                                                  |
+| `importExtension`              | `'.js' \| '.ts' \| ''` | `'.js'`              | File extension used in generated import statements                                                                                                                    |
+| `includePhantomTypeParameters` | `boolean`              | `false`              | Include [phantom type parameters](#phantom-types) as function arguments in generated BCS types                                                                        |
+| `fullnodeUrls`                 | network URL map        | Sui public fullnodes | Override the Mainnet or Testnet fullnode used to fetch onchain package summaries                                                                                      |
 
 ### Package configuration
 
@@ -84,12 +85,14 @@ local (from source) or onchain (fetched from a network).
 
 #### Local packages
 
-| Option        | Type                     | Required | Description                                               |
-| ------------- | ------------------------ | -------- | --------------------------------------------------------- |
-| `package`     | `string`                 | yes      | Package identifier (for example, `@local-pkg/my-package`) |
-| `path`        | `string`                 | yes      | Path to the Move package directory                        |
-| `packageName` | `string`                 | no       | Custom name for generated code directory                  |
-| `generate`    | `PackageGenerateOptions` | no       | Control what gets generated from this package             |
+| Option            | Type                     | Required | Description                                                                                      |
+| ----------------- | ------------------------ | -------- | ------------------------------------------------------------------------------------------------ |
+| `package`         | `string`                 | yes      | Package identifier (for example, `@local-pkg/my-package`)                                        |
+| `path`            | `string`                 | yes      | Path to the Move package directory                                                               |
+| `packageName`     | `string`                 | no       | Custom name for generated code directory                                                         |
+| `generate`        | `PackageGenerateOptions` | no       | Control what gets generated from this package                                                    |
+| `configArguments` | `ConfigArguments`        | no       | Map this package's function parameters to a [runtime config object](#the-configarguments-option) |
+| `bcsOverrides`    | `BcsOverrides`           | no       | Replace generated BCS types with [custom types](#the-bcsoverrides-option)                        |
 
 ```typescript
 {
@@ -103,12 +106,15 @@ local (from source) or onchain (fetched from a network).
 For packages already deployed onchain, generate code directly from a package ID or MVR name without
 needing local source code:
 
-| Option        | Type                     | Required | Description                                   |
-| ------------- | ------------------------ | -------- | --------------------------------------------- |
-| `package`     | `string`                 | yes      | Package ID or MVR name                        |
-| `packageName` | `string`                 | yes      | Name for the generated code directory         |
-| `network`     | `'mainnet' \| 'testnet'` | yes      | Network to fetch the package from             |
-| `generate`    | `PackageGenerateOptions` | no       | Control what gets generated from this package |
+| Option            | Type                     | Required | Description                                                                                      |
+| ----------------- | ------------------------ | -------- | ------------------------------------------------------------------------------------------------ |
+| `package`         | `string`                 | yes      | Package ID or name emitted into generated code                                                   |
+| `sourcePackageId` | `string`                 | no       | Package ID to fetch when generating an unpublished package name                                  |
+| `packageName`     | `string`                 | yes      | Name for the generated code directory                                                            |
+| `network`         | `'mainnet' \| 'testnet'` | yes      | Network to resolve and fetch the package from                                                    |
+| `generate`        | `PackageGenerateOptions` | no       | Control what gets generated from this package                                                    |
+| `configArguments` | `ConfigArguments`        | no       | Map this package's function parameters to a [runtime config object](#the-configarguments-option) |
+| `bcsOverrides`    | `BcsOverrides`           | no       | Replace generated BCS types with [custom types](#the-bcsoverrides-option)                        |
 
 ```typescript
 {
@@ -267,6 +273,271 @@ src/contracts/
 
 Set `prune: false` to generate all dependency modules with their full types and functions.
 
+## The `configArguments` option
+
+SDKs built on generated bindings often spend a lot of wrapper code passing values from a per-network
+config object (package IDs, registry or treasury object IDs, pool addresses) into generated function
+calls. The `configArguments` option moves that mapping into codegen: declare which Move types (or
+package addresses) come from a config object, and the generated functions accept that config object
+directly.
+
+`configArguments` is set on a package entry and maps config keys to matchers. Matchers reference
+types as `module::Type`, optionally qualified with a package identifier from the `packages` config
+or an address:
+
+```typescript
+const config: SuiCodegenConfig = {
+	output: './src/contracts',
+	packages: [
+		{
+			package: '@myapp/core',
+			path: './move/core',
+			configArguments: {
+				// Every parameter of this type resolves from `config.registry`
+				registry: { type: 'registry::Registry' },
+				// Generic type: matches every instantiation, config value must be a resolver function
+				pool: { type: 'pool::Pool' },
+				// Instantiated generic: only matches this exact instantiation
+				suiPool: { type: 'pool::Pool<0x2::sui::SUI>' },
+				// Function matcher: configures a single function's parameter
+				adminCap: { function: 'admin::set_fees', parameterName: 'cap' },
+				// Package entry: adds a config key that overrides the package address used for calls
+				corePackageId: { package: '@myapp/core' },
+			},
+		},
+		{
+			package: '@myapp/vaults',
+			path: './move/vaults',
+			configArguments: {
+				// Types from other packages are referenced by their package identifier
+				vaultPool: { type: '@myapp/core::pool::Pool' },
+			},
+		},
+	],
+};
+```
+
+Matcher rules:
+
+- A bare `module::Type` refers to a type from the package the config is declared on.
+- Types from other packages in the run use their package identifier (for example,
+  `@myapp/core::pool::Pool`) and must be dependencies of the declaring package.
+- Types can also be referenced by an explicit address (for example, `0x2::sui::SUI`). Addresses
+  aren't validated, so only use addresses that are valid on every network your generated code
+  targets.
+- Partially instantiated generics like `Pool<T>` are not supported. Use an uninstantiated matcher
+  with a resolver function instead.
+- Function matchers can target a parameter by `parameterName` or `parameterIndex`. Both can be
+  omitted when the function has a single argument.
+- A key can declare an array of matchers. If they span multiple types, the config value must be a
+  resolver function.
+- Invalid matchers fail at generation time, and keys that never match any generated parameter
+  produce a warning.
+
+### Generated output
+
+For each function with matched parameters, the generated options gain an optional `config` property
+typed with the keys that function uses. Matched parameters become optional in `arguments`, and an
+explicitly passed argument always takes precedence over the config value:
+
+```typescript
+
+	package?: string;
+	arguments: BorrowArguments; // `pool` is optional here
+	config?: {
+		pool: (ctx: ConfigResolverContext) => string | TransactionObjectArgument;
+		corePackageId?: string;
+	};
+	typeArguments: [string];
+}
+
+	const packageAddress = options.package ?? options.config?.corePackageId ?? '@myapp/core';
+	// ...
+	pool: options.arguments?.pool ?? options.config?.pool?.({ ... }),
+}
+```
+
+Keys bound to a single concrete type accept a plain value (an object ID or a transaction argument).
+Keys that match a generic type, or multiple types, must be resolver functions, because a single ID
+can't be correct for every instantiation. A resolver can also return a transaction callback
+(`(ctx) => (tx) => ...`) to build the argument dynamically. Resolvers receive the matched
+parameter's own type arguments plus call-site metadata:
+
+```typescript
+
+	typeArguments: string[]; // canonical for concrete instantiations; as-provided for generic positions
+	packageAddress: string;
+	moduleName: string;
+	functionName: string;
+	parameterName?: string; // Move parameter name, when the summary includes names
+	parameterIndex: number; // position in the generated function's arguments
+}
+```
+
+This makes resolvers reusable across functions that use the type in different positions:
+
+```typescript
+const myConfig = {
+	registry: '0x123...',
+	pool: (ctx: ConfigResolverContext) => poolsByCoinType[ctx.typeArguments[0]],
+	suiPool: '0x456...',
+	adminCap: '0x789...',
+	corePackageId: '0xabc...',
+} satisfies CoreConfig;
+
+tx.add(
+	borrow({
+		arguments: { amount: 100n },
+		config: myConfig,
+		typeArguments: ['0x2::sui::SUI'],
+	}),
+);
+```
+
+Each package's output also includes a `config-arguments.ts` file with an interface covering the
+package's config keys, named after the package's `packageName` (for example, `packageName: 'core'`
+produces `CoreConfig`). Use it with `satisfies` when defining your config object, as shown above. An
+SDK spanning multiple packages can check one shared config object against the intersection of the
+per-package interfaces:
+
+```typescript
+const myConfig = { ... } satisfies CoreConfig & MarginConfig;
+```
+
+### Name refinement
+
+When a signature has two parameters of the same matched type (for example, `base_pool` and
+`quote_pool`, both `Pool<T>`), a bare type matcher matches both: the key's config value must then be
+a resolver function, which receives each parameter's own context. To give each parameter its own
+config key instead, refine the matchers with the Move parameter names:
+
+```typescript
+configArguments: {
+	basePool: { type: 'pool::Pool', parameterName: 'base_pool' },
+	quotePool: { type: 'pool::Pool', parameterName: 'quote_pool' },
+},
+```
+
+Parameter names are only available in summaries generated from local packages. For onchain packages
+without parameter names, use function matchers with `parameterIndex` to target individual
+parameters.
+
+### Package address precedence
+
+For package entries, the address used for a generated call is resolved in this order:
+
+1. An explicit `options.package` argument
+2. The config key declared by the package entry (for example, `config.corePackageId`)
+3. The generated default (the package's MVR name or address)
+
+On networks where the package's MVR name doesn't resolve, supply the deployed package ID through the
+config object. Package entries only apply to the main package's generated modules, and for packages
+generated without an MVR name or address `package` remains required.
+
+## The `bcsOverrides` option
+
+Generated BCS types mirror the raw Move layout, but the raw layout is often not the shape an SDK
+wants to expose: a `u64` field might be a 1e9 fixed-point price, or a struct like
+`i64::I64 { magnitude: u64, is_negative: bool }` is really a signed integer. The `bcsOverrides`
+option replaces generated BCS types with custom ones — typically built with
+[`transform`](/bcs#transforms) — so parsed values come out in the shape you want and inputs accept
+it.
+
+`bcsOverrides` is set on a package entry as an array. Every entry names the Move `type` it replaces
+and the `source` module the replacement is imported from, and can optionally narrow the entry to
+specific `fields`:
+
+```typescript
+const config: SuiCodegenConfig = {
+	output: './src/contracts',
+	packages: [
+		{
+			package: '@local-pkg/deepbook_predict',
+			path: './move/deepbook_predict',
+			bcsOverrides: [
+				// Replace a datatype's generated declaration: every generated layout that
+				// references it uses the custom type. Imports `I64` from the source module.
+				{ type: 'fixed_math::i64::I64', source: './src/bcs/i64.ts' },
+
+				// `fields` narrows an entry to the field sites matching a glob. Entries are tried
+				// in declaration order and the first match wins, so narrow entries go first.
+				{ type: 'u64', fields: 'order::*.*_price', source: './src/bcs/units.ts#Price9' },
+
+				// A type with no generated declaration is replaced wherever it is rendered —
+				// here, every remaining `u64` parses to a bigint instead of a decimal string.
+				{ type: 'u64', source: './src/bcs/integers.ts#U64' },
+
+				// A whole-type match wins over its elements, so this replaces the vector itself
+				// rather than letting the `u64` rule apply to its items.
+				{ type: 'vector<u64>', source: './src/bcs/units.ts#Payouts' },
+			],
+		},
+	],
+};
+```
+
+The replacement module exports plain BCS types:
+
+```typescript
+// ./src/bcs/units.ts
+
+/** 1e9 fixed-point u64 exposed as a decimal number. */
+const Price9 = bcs.u64().transform({
+	input: (value: number) => BigInt(Math.round(value * 1e9)).toString(),
+	output: (raw) => Number(raw) / 1e9,
+});
+
+```
+
+The custom type's inferred input and output types flow through the generated code, so
+`Node.parse(bytes).levels` is a `number[]` and `Node.serialize` accepts one.
+
+Entry rules:
+
+- `type` uses the same package scoping as `configArguments` matchers (bare `module::Type` for the
+  declaring package, package identifiers, explicit addresses), and additionally accepts
+  named-address labels from the package's summaries (for example, `fixed_math::i64::I64`) so entries
+  can target dependency packages that are not codegen-run entries.
+- A datatype entry written without type arguments or `fields` replaces the type's generated
+  **declaration**: the module exports the custom type under the Move type's name, and every use
+  picks it up because uses already reference the declaration. For a generic type the source must
+  export a function `(...typeParameters: BcsType<any>[]) => BcsType<any>` mirroring the generated
+  call convention.
+- Every other entry replaces the type **wherever it is rendered**. That covers types with no
+  declaration to replace (primitives, `vector`, and the stdlib types generated layouts serialize
+  inline — `String`, `Option`, `ID`/`UID`), a single instantiation of a generic
+  (`pool::Pool<0x2::sui::SUI>`), and any entry narrowed with `fields`.
+- Replacement applies at **any depth**, because the type renderer consults overrides as it recurses.
+  An override on `u64` also replaces the `u64` inside `vector<u64>` and `Option<u64>`. A whole-type
+  match wins over its elements, so an entry for `vector<u64>` replaces the vector rather than its
+  items.
+- `fields` restricts an entry to the field sites matching one glob, where `*` matches any run of
+  characters. Sites are written `module::Type.field`, or `module::Type.variant.field` for enum
+  variant fields (positional fields are named `pos0`, `pos1`, …). A glob that names no module —
+  `Order.*_price` — is matched against the `Type.field` suffix, so it applies in every module. An
+  entry with `fields` never replaces a declaration, since a declaration exists once for every use.
+- At each use site, matching entries are tried in **declaration order and the first match wins**. An
+  unrestricted datatype declaration remains the fallback for sites not matched by an earlier
+  field-restricted entry. There is no specificity scoring, so put narrow entries before broad ones.
+- `source` is an import specifier, optionally suffixed with `#ExportName`. Relative specifiers
+  resolve against the config file's directory and are rewritten into relative imports from each
+  generated file, with their extension replaced by the configured `importExtension` (so a
+  `./src/bcs/units.ts` source is imported as `units.js` by default); bare package specifiers are
+  emitted as-is. Without a fragment, datatype entries import the Move type's name; entries whose
+  `type` is a primitive or `vector` must include one.
+- Replacement modules must be self-contained: a module whose export replaces a declaration can't
+  import generated modules that reference the replaced type, because that would create a circular
+  import. Declare the raw layout inline when building a transform.
+- A replacement built with `.transform()` is a plain `BcsType`, so a type replaced that way loses
+  the `MoveStruct` helpers (`typeTag()`, `resolveTypeTag()`, `get()`, `getMany()`). Extend
+  `MoveStruct` instead if the replaced type needs them.
+- An entry that matches nothing is not an error. A shared set of overrides can be applied to several
+  packages even when only some of them have fields of a given type.
+
+Overrides only affect generated BCS layouts (parsing and serializing structs, enums, and events,
+including `MoveStruct.get()`). Generated transaction-building functions serialize their arguments
+from Move type tags at runtime, so pure function arguments are unaffected.
+
 ## Phantom types
 
 In Move, phantom type parameters are type parameters that only appear at the type level and don't
@@ -370,8 +641,8 @@ async function readCounter(client: ClientWithCoreApi, id: string) {
 ```
 
 > **Warning:** Always use `content`, not `objectBcs`, when parsing with generated types. The `objectBcs` field
-> contains a full object envelope with additional metadata that will cause parsing to fail. See the
-> [Core API docs](/sui/clients/core#objectbcs) for details.
+> contains a full object envelope with additional metadata that causes parsing to fail. See
+> [Querying data](/sui/clients/querying#objectbcs) for details.
 
 ### Getting type tags
 
@@ -440,11 +711,15 @@ const balanceType = await Balance.resolveTypeTag({
 
 ### Using with MVR (Move Version Registry)
 
-If your package is registered on MVR, the generated code works without additional configuration.
+If your package is registered on MVR, the generated code works without additional configuration. The
+configured name is preserved in generated function targets and type tags. At runtime MVR resolves
+function packages and type origins independently for the client's network.
 
 ### Local packages
 
-For local packages using `@local-pkg/*` identifiers, configure your client with package overrides:
+For local packages using `@local-pkg/*` identifiers, configure package overrides for Move calls and
+first-level type overrides for each local type used as a transaction type argument or resolved for a
+query:
 
 ```typescript
 
@@ -456,6 +731,9 @@ const client = new SuiGrpcClient({
 			packages: {
 				'@local-pkg/counter': '0xYOUR_PACKAGE_ID',
 			},
+			types: {
+				'@local-pkg/counter::counter::Counter': '0xTYPE_ORIGIN::counter::Counter',
+			},
 		},
 	},
 });
@@ -474,6 +752,7 @@ const GRPC_URLS = {
 const PACKAGE_IDS = {
 	testnet: {
 		counter: '0xYOUR_PACKAGE_ID',
+		counterType: '0xTYPE_ORIGIN::counter::Counter',
 	},
 };
 
@@ -488,6 +767,9 @@ const dAppKit = createDAppKit({
 					packages: {
 						'@local-pkg/counter': PACKAGE_IDS[network].counter,
 					},
+					types: {
+						'@local-pkg/counter::counter::Counter': PACKAGE_IDS[network].counterType,
+					},
 				},
 			},
 		});

package/dist/dapp-kit/getting-started/react.md

@@ -1,6 +1,6 @@
 # React
 
-> Set up dApp Kit in a React application.
+> Set up dApp Kit in a React application
 
 This guide walks you through integrating dApp Kit into a React application.
 
@@ -147,7 +147,7 @@ function TransferButton() {
 | [`useCurrentAccount`](/dapp-kit/react/hooks/use-current-account)     | Currently selected account               |
 | [`useCurrentWallet`](/dapp-kit/react/hooks/use-current-wallet)       | Currently connected wallet               |
 | [`useCurrentNetwork`](/dapp-kit/react/hooks/use-current-network)     | Current network                          |
-| [`useCurrentClient`](/dapp-kit/react/hooks/use-current-client)       | SuiClient for current network            |
+| [`useCurrentClient`](/dapp-kit/react/hooks/use-current-client)       | Current Sui client instance              |
 | [`useWallets`](/dapp-kit/react/hooks/use-wallets)                    | List of available wallets                |
 
 ## Components

package/dist/dapp-kit/getting-started/vue.md

@@ -1,6 +1,6 @@
 # Vue
 
-> Set up dApp Kit in a Vue application.
+> Set up dApp Kit in a Vue application
 
 This guide walks you through integrating dApp Kit into a Vue application using Web Components and
 direct store access.
@@ -174,7 +174,7 @@ Access these stores through `dAppKit.stores`:
 | ----------------- | ------------------------------------------------- |
 | `$connection`     | Connection state with wallet, account, and status |
 | `$currentNetwork` | Current network string                            |
-| `$currentClient`  | SuiClient for current network                     |
+| `$currentClient`  | Current Sui client instance                       |
 | `$wallets`        | List of available wallets                         |
 
 See [State Management](/dapp-kit/state) for full documentation.

package/dist/dapp-kit/llms-index.md

@@ -3,11 +3,11 @@
 
 - [Sui dApp Kit](..md): Build Sui apps with framework-agnostic core and React bindings.
 - [@mysten/create-dapp](./getting-started/create-dapp.md): Create a Sui app with one command using the create-dapp CLI scaffolding tool.
-- [React](./getting-started/react.md): Set up dApp Kit in a React application.
+- [React](./getting-started/react.md): Set up dApp Kit in a React application
 - [Next.js](./getting-started/next-js.md): Set up dApp Kit in a Next.js application.
-- [Vue](./getting-started/vue.md): Set up dApp Kit in a Vue application.
+- [Vue](./getting-started/vue.md): Set up dApp Kit in a Vue application
 - [DApp Kit Instance](./dapp-kit-instance.md): Create and configure a DAppKit instance for wallet and client management
-- [State](./state.md): Access and subscribe to wallet connection state in dApp Kit.
+- [State](./state.md): Access and subscribe to wallet connection state in dApp Kit
 - [Connect Wallet](./actions/connect-wallet.md): Programmatically connect to a Sui wallet using the dApp Kit connectWallet action.
 - [Disconnect Wallet](./actions/disconnect-wallet.md): Programmatically disconnect from a Sui wallet using the dApp Kit disconnectWallet action.
 - [Sign and Execute Transaction](./actions/sign-and-execute-transaction.md): Sign and execute a transaction on the Sui network using the connected wallet.
@@ -19,7 +19,7 @@
 - [React Hooks](./react/hooks.md): React hooks for accessing dApp Kit state and actions in Sui applications.
 - [useDAppKit](./react/hooks/use-dapp-kit.md): React hook to access the full dApp Kit instance for calling actions directly.
 - [useCurrentAccount](./react/hooks/use-current-account.md): React hook to get the currently selected wallet account in a Sui dApp.
-- [useCurrentClient](./react/hooks/use-current-client.md): React hook to get the current Sui client instance for the active network.
+- [useCurrentClient](./react/hooks/use-current-client.md): React hook to get the current Sui client instance for the active network
 - [useCurrentNetwork](./react/hooks/use-current-network.md): React hook to get the currently selected Sui network in dApp Kit.
 - [useCurrentWallet](./react/hooks/use-current-wallet.md): React hook to get the currently connected wallet in a Sui dApp.
 - [useWalletConnection](./react/hooks/use-wallet-connection.md): React hook to manage wallet connection status and information in a Sui dApp.

package/dist/dapp-kit/react/hooks/use-current-client.md

@@ -1,13 +1,14 @@
 # useCurrentClient
 
-> React hook to get the current Sui client instance for the active network.
+> React hook to get the current Sui client instance for the active network
 
 The `useCurrentClient` hook provides access to the blockchain client instance for the current
 network.
 
-> **Note:** By default, this returns a `SuiClient` instance when using the standard setup. However, the dApp
-> Kit supports any client that implements the Sui core API, making it flexible for different
-> blockchain implementations.
+> **Note:** With the standard setup, this returns the `SuiGrpcClient` instance created by `createClient`. More
+> generally, it returns whatever client type your dApp Kit instance creates, as long as that client
+> implements the Sui Core API. Application code should call the concrete client's top-level methods
+> directly.
 
 > **Warning:** All dApp Kit hooks must be used within components that are descendants of
 > [`DAppKitProvider`](../dapp-kit-provider). Using them outside will result in an error.
@@ -32,5 +33,5 @@ network.
 ## Return value
 
 ```tsx
-SuiClient;
+ReturnType<typeof dAppKit.getClient>;
 ```

package/dist/dapp-kit/state.md

@@ -1,6 +1,6 @@
 # State
 
-> Access and subscribe to wallet connection state in dApp Kit.
+> Access and subscribe to wallet connection state in dApp Kit
 
 The Sui dApp Kit SDK uses [nanostores](https://github.com/nanostores/nanostores) for state
 management, providing a lightweight, framework-agnostic solution that works across React, Vue,
@@ -100,7 +100,7 @@ This store is read-only. Use `dAppKit.switchNetwork()` to change networks.
 
 ### Current client store (`$currentClient`)
 
-Contains the SuiClient instance for the current network:
+Contains the Sui client instance for the current network:
 
 ```typescript
 const client = dAppKit.stores.$currentClient.get();

package/dist/kiosk/advanced-examples.md

@@ -1,6 +1,6 @@
 # Advanced Examples
 
-> Advanced Kiosk SDK usage patterns and code examples for complex scenarios.
+> Advanced Kiosk SDK usage patterns and code examples for complex scenarios
 
 # Some extended examples
 
@@ -14,8 +14,8 @@ const bullsharkType = `${packageId}::suifrens::SuiFren<${packageId}::bullshark::
 const capyType = `${packageId}::suifrens::SuiFren<${packageId}::capy::Capy>`;
 
 // initialize the client with the kiosk extension.
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('mainnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.mainnet.sui.io:443',
 	network: 'mainnet',
 }).$extend(kiosk());
 ```

package/dist/kiosk/from-v1.md

@@ -1,6 +1,6 @@
 # Migrating from Kiosk SDK V1
 
-> Migrate from Kiosk SDK v1 to the current version with the builder-pattern API.
+> Migrate from Kiosk SDK v1 to the current version with the builder-pattern API
 
 The original version of Kiosk SDK provided basic experimentation with the Kiosk API. The new version
 of the SDK (0.7+) provides a more robust experience for building kiosk/transfer policy transactions.
@@ -46,8 +46,8 @@ Using the new SDK, you can build the same transaction as follows:
 ```typescript
 
 // You need to do this only once and re-use it in the application.
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('mainnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.mainnet.sui.io:443',
 	network: 'mainnet',
 }).$extend(kiosk());
 
@@ -98,8 +98,8 @@ Using the new SDK, you can build the same transaction as follows:
 ```typescript
 
 // You need to do this only once and re-use it in the application.
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('mainnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.mainnet.sui.io:443',
 	network: 'mainnet',
 }).$extend(kiosk());
 
@@ -198,8 +198,8 @@ Using the new SDK, you can build the same transaction as follows:
 ```typescript
 
 // You need to do this only once and re-use it in the application.
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('mainnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.mainnet.sui.io:443',
 	network: 'mainnet',
 }).$extend(kiosk());
 
@@ -296,8 +296,8 @@ On the new SDK, the same transaction can be built as follows:
 ```typescript
 
 // You need to do this only once and re-use it in the application.
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('mainnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.mainnet.sui.io:443',
 	network: 'mainnet',
 }).$extend(kiosk());
 

package/dist/kiosk/index.md

@@ -1,6 +1,6 @@
 # Kiosk SDK
 
-> TypeScript SDK for interacting with Sui Kiosk onchain commerce.
+> TypeScript SDK for interacting with Sui Kiosk onchain commerce
 
 Kiosk SDK is a tool to interact with Sui and Mysten Kiosk. You can use it to query kiosk related
 data, build transactions to interact, and extend Kiosk to support custom rules.
@@ -16,7 +16,10 @@ npm i @mysten/kiosk
 The Kiosk SDK exports a client extension that integrates with Sui clients. Add it to your client
 using `$extend(kiosk())` to access kiosk functionality through `client.kiosk`.
 
-> The Kiosk SDK requires `SuiJsonRpcClient` or `SuiGraphQLClient`. It does not work with
-> `SuiGrpcClient` because it uses event queries that are not available in gRPC.
+The Kiosk extension accepts any Sui client that implements `ClientWithCoreApi`. Use `SuiGrpcClient`
+for new Kiosk code; `SuiGraphQLClient` and the deprecated `SuiJsonRpcClient` are also compatible.
+
+> **Note:** The gRPC object API returns Display v2 metadata. Use GraphQL or JSON-RPC when reading objects
+> whose types still rely on legacy Display metadata.
 
 - [Read more about setting up the Kiosk client extension](/kiosk/kiosk-client/introduction)

package/dist/kiosk/kiosk-client/introduction.md

@@ -1,14 +1,17 @@
 # Kiosk Client
 
-> Introduction to the KioskClient extension for querying and managing kiosks on Sui.
+> Introduction to the KioskClient extension for querying and managing kiosks on Sui
 
 The Kiosk SDK exports a client extension that provides all Kiosk functionality.
 
 > We recommend you keep only one client instance throughout your app or script. For example, in
 > React, you'd use a context to provide the client.
 
-> The Kiosk SDK requires `SuiJsonRpcClient` or `SuiGraphQLClient`. It does not work with
-> `SuiGrpcClient` because it uses event queries that are not available in gRPC.
+The Kiosk extension accepts any Sui client that implements `ClientWithCoreApi`. Use `SuiGrpcClient`
+for new Kiosk code; `SuiGraphQLClient` and the deprecated `SuiJsonRpcClient` are also compatible.
+
+> **Note:** The gRPC object API returns Display v2 metadata. Use GraphQL or JSON-RPC when reading objects
+> whose types still rely on legacy Display metadata.
 
 ## Setting up the kiosk extension
 
@@ -20,8 +23,8 @@ require constantly changing the package IDs).
 
 ```typescript
 
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('testnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.testnet.sui.io:443',
 	network: 'testnet',
 }).$extend(kiosk());
 
@@ -36,8 +39,8 @@ for the rules and extensions you want to use.
 
 ```typescript
 
-const client = new SuiJsonRpcClient({
-	url: getJsonRpcFullnodeUrl('devnet'),
+const client = new SuiGrpcClient({
+	baseUrl: 'https://fullnode.devnet.sui.io:443',
 	network: 'devnet',
 }).$extend(
 	kiosk({