@mysten/docs 0.1.17 → 0.1.19

package/dist/payment-kit/payment-processing.md

@@ -1,6 +1,6 @@
 # Payment Processing
 
-> Process payments and handle transaction results
+> Process registry-based and ephemeral payments and handle transaction results on Sui.
 
 > **Note:** This package is in active development and should be used with caution. APIs are experimental and
 > subject to breaking changes without notice. We recommend thoroughly testing any implementation
@@ -9,15 +9,15 @@
 Payment Kit provides two distinct payment processing models, each designed for different use cases.
 This guide explains how each model works and when to use them.
 
-## Payment Models Overview
+## Payment models overview
 
-### Registry-Based Payments
+### Registry-based payments
 
-Registry-based payments create a persistent `PaymentRecord` stored on-chain in a `PaymentRegistry`.
+Registry-based payments create a persistent `PaymentRecord` stored onchain in a `PaymentRegistry`.
 This model provides:
 
 - **Duplicate Prevention**: A payment with the same parameters can only be processed once
-- **Verifiable Proof**: On-chain proof that a payment was made
+- **Verifiable Proof**: Onchain proof that a payment was made
 - **Expiration Management**: Records can be deleted after a configurable period
 - **Centralized Tracking**: All payments are indexed under a specific registry
 
@@ -28,12 +28,12 @@ This model provides:
 - Invoice payments
 - Any scenario requiring duplicate prevention
 
-### Ephemeral Payments
+### Ephemeral payments
 
-Ephemeral payments process transfers without creating persistent on-chain records. This model
+Ephemeral payments process transfers without creating persistent onchain records. This model
 provides:
 
-- **Lower Gas Costs**: No on-chain storage means cheaper transactions
+- **Lower Gas Costs**: No onchain storage means cheaper transactions
 - **Flexibility**: No registry configuration required
 
 **When to Use:**
@@ -41,14 +41,14 @@ provides:
 - Tipping/donations
 - Recurring payments with external tracking
 - High-frequency microtransactions
-- Scenarios where duplicate prevention is handled off-chain
+- Scenarios where duplicate prevention is handled offchain
 
-## How Payment Keys Work
+## How payment keys work
 
 Payment Kit uses a composite key system to uniquely identify payments. Understanding this is crucial
 for using the SDK effectively.
 
-### Payment Key Components
+### Payment key components
 
 A payment key is derived from four parameters:
 
@@ -61,7 +61,7 @@ type PaymentKeyArgs = {
 };
 ```
 
-### Key Generation
+### Key generation
 
 When you process a registry payment, Payment Kit hashes these parameters to create a unique key:
 
@@ -89,7 +89,7 @@ const tx2 = client.paymentKit.tx.processRegistryPayment({
 });
 ```
 
-### Changing Any Component Creates a New Key
+### Changing any component creates a new key
 
 Each component affects the payment key. Changing any parameter creates a different payment. This
 means, as an example, that a `nonce` can be reused for a different payment, if the `coinType` or
@@ -125,11 +125,11 @@ const payment3 = {
 // All three are unique payments that can be processed separately
 ```
 
-## Processing Registry-Based Payments
+## Processing registry-based payments
 
 Let's walk through a complete registry payment workflow:
 
-### Step 1: Create the Transaction
+### Step 1: Create the transaction
 
 ```ts
 // Define your payment parameters
@@ -145,7 +145,7 @@ const paymentParams = {
 const tx = client.paymentKit.tx.processRegistryPayment(paymentParams);
 ```
 
-### What Happens On-Chain
+### What happens onchain
 
 When this transaction executes, Payment Kit:
 
@@ -155,7 +155,7 @@ When this transaction executes, Payment Kit:
 4. **Creates** a `PaymentRecord` dynamic field on the registry
 5. **Emits** a `PaymentReceipt` event
 
-### Step 2: Execute the Transaction
+### Step 2: Execute the transaction
 
 ```ts
 const result = await client.signAndExecuteTransaction({
@@ -176,7 +176,7 @@ if (result.$kind === 'FailedTransaction') {
 console.log('Transaction digest:', result.Transaction.digest);
 ```
 
-### Step 3: Extract the Receipt
+### Step 3: Extract the receipt
 
 ```ts
 // Find the PaymentReceipt event
@@ -197,7 +197,7 @@ if (receiptEvent) {
 }
 ```
 
-### Step 4: Verify the Payment Record
+### Step 4: Verify the payment record
 
 ```ts
 // Query the payment record to confirm it exists
@@ -216,11 +216,11 @@ if (record) {
 }
 ```
 
-## Processing Ephemeral Payments
+## Processing ephemeral payments
 
 Ephemeral payments follow a simpler flow without creating persistent records:
 
-### Creating an Ephemeral Payment
+### Creating an ephemeral payment
 
 ```ts
 // No registry needed for ephemeral payments
@@ -246,7 +246,7 @@ if (result.$kind === 'FailedTransaction') {
 }
 ```
 
-### What Happens On-Chain
+### What happens onchain
 
 For ephemeral payments, Payment Kit:
 
@@ -254,9 +254,9 @@ For ephemeral payments, Payment Kit:
 2. **Transfers** the coins from sender to receiver
 3. **Emits** a `PaymentReceipt` event
 
-**Note:** No `PaymentRecord` is created, so duplicate payments are not prevented.
+No `PaymentRecord` is created, so duplicate payments are not prevented.
 
-### Extracting the Receipt
+### Extracting the receipt
 
 ```ts
 const receiptEvent = result.Transaction.events?.find((event) =>
@@ -269,9 +269,9 @@ if (receiptEvent) {
 }
 ```
 
-## Advanced Payment Scenarios
+## Advanced payment scenarios
 
-### Processing Multiple Payments in One Transaction
+### Processing multiple payments in one transaction
 
 You can combine multiple payment operations in a single transaction:
 
@@ -307,7 +307,7 @@ const result = await client.signAndExecuteTransaction({
 });
 ```
 
-### Working with Custom Coin Types
+### Working with custom coin types
 
 Payment Kit works with any Sui coin type:
 
@@ -330,9 +330,9 @@ const result = await client.signAndExecuteTransaction({
 });
 ```
 
-## Gas Considerations
+## Gas considerations
 
-### Registry Payments
+### Registry payments
 
 Registry payments have higher gas costs because they:
 
@@ -340,7 +340,7 @@ Registry payments have higher gas costs because they:
 - Write data to the registry object
 - Perform duplicate checking
 
-### Ephemeral Payments
+### Ephemeral payments
 
 Ephemeral payments have lower gas costs because they:
 
@@ -348,9 +348,9 @@ Ephemeral payments have lower gas costs because they:
 - Don't create persistent storage
 - Skip duplicate checking
 
-## Best Practices
+## Best practices
 
-1. **Use Meaningful Nonces**: Choose nonces that help you track payments (e.g., `order-123`,
+1. **Use Meaningful Nonces**: Choose nonces that help you track payments (for example, `order-123`,
    `invoice-456`)
 
 2. **Store Receipts Off-Chain**: Save `PaymentReceipt` events in your database for quick lookup
@@ -358,7 +358,7 @@ Ephemeral payments have lower gas costs because they:
 3. **Handle Duplicate Attempts**: Gracefully handle duplicate payment attempts with proper error
    messages
 
-4. **Verify Before Delivery**: Always verify payment records before delivering goods/services
+4. **Verify Before Delivery**: Always verify payment records before delivering goods or services
 
 5. **Choose the Right Model**:
    - Use registry payments for critical transactions requiring duplicate prevention
@@ -367,6 +367,6 @@ Ephemeral payments have lower gas costs because they:
 6. **Monitor Expiration**: If using registry payments, be aware of the expiration policy and query
    records before they expire
 
-## Next Steps
+## Next steps
 
 - [Registry Management](./registry-management) - Learn how to create and configure custom registries

package/dist/payment-kit/registry-management.md

@@ -1,6 +1,6 @@
 # Registry Management
 
-> Manage payment registries and accepted coin types
+> Create, configure, and manage payment registries and accepted coin types on Sui.
 
 > **Note:** This package is in active development and should be used with caution. APIs are experimental and
 > subject to breaking changes without notice. We recommend thoroughly testing any implementation
@@ -9,16 +9,16 @@
 Payment registries are the core of Payment Kit's duplicate prevention and payment tracking system.
 This guide covers creating, configuring, and managing payment registries.
 
-## Understanding Payment Registries
+## Understanding payment registries
 
-A `PaymentRegistry` is an on-chain object that:
+A `PaymentRegistry` is an onchain object that:
 
 - Stores `PaymentRecord` dynamic fields for each unique payment
 - Manages configuration settings (expiration, fund management)
 - Can be owned and administered by a specific account
 - Provides namespaced payment tracking
 
-### Default Registry
+### Default registry
 
 Payment Kit provides a default registry that's ready to use:
 
@@ -33,7 +33,7 @@ const tx = client.paymentKit.tx.processRegistryPayment({
 });
 ```
 
-### When to Create a Custom Registry
+### When to create a custom registry
 
 Consider creating your own registry when:
 
@@ -43,11 +43,11 @@ Consider creating your own registry when:
 - You need better indexing of your payments
 - You want to avoid potential congestion on the default registry
 
-## Creating a Registry
+## Creating a registry
 
-### Basic Registry Creation
+### Basic registry creation
 
-Creating a registry is simple - you only need to provide a unique name:
+Creating a registry is straightforward. You only need to provide a unique name:
 
 ```ts
 // Create a new registry
@@ -73,14 +73,14 @@ console.log('Registry created!');
 console.log('Transaction:', result.Transaction.digest);
 ```
 
-### What Gets Created
+### What gets created
 
 When you create a registry, two objects are created:
 
 1. **PaymentRegistry**: The registry object that stores payment records
 2. **RegistryAdminCap**: A capability object that grants admin permissions
 
-### Extracting the Admin Capability
+### Extracting the admin capability
 
 The `RegistryAdminCap` is crucial for configuring your registry:
 
@@ -104,7 +104,7 @@ if (adminCapObject && 'objectId' in adminCapObject) {
 }
 ```
 
-### Deriving the Registry ID
+### Deriving the registry ID
 
 Payment Kit derives registry IDs deterministically from the registry name:
 
@@ -118,15 +118,15 @@ console.log('Registry ID:', registryId);
 
 This allows you to reference registries by name throughout your application.
 
-## Registry Configuration
+## Registry configuration
 
 Registries have two main configuration options:
 
-### 1. Epoch Expiration Duration
+### Step 1: Epoch expiration duration
 
 Controls how long payment records persist before they can be deleted.
 
-**Default**: 30 epochs (~30 days on mainnet)
+**Default**: 30 epochs (~30 days on Mainnet)
 
 ```ts
 // Set expiration to 60 epochs
@@ -167,7 +167,7 @@ anyone can delete the record to reclaim storage fees:
 - **Medium expiration (30-60 epochs)**: Standard e-commerce transactions
 - **Long expiration (180+ epochs)**: Important financial records requiring long-term verification
 
-### 2. Registry Managed Funds
+### Step 2: Registry managed funds
 
 Controls whether payments must be sent to the registry itself for later withdrawal.
 
@@ -189,7 +189,7 @@ await client.signAndExecuteTransaction({
 console.log('Registry now manages funds');
 ```
 
-**How It Works:**
+**How it works:**
 
 When enabled:
 
@@ -219,7 +219,7 @@ const tx = client.paymentKit.tx.processRegistryPayment({
 - Scenarios with very high transaction volumes
 - Simplified accounting and reconciliation
 
-### Configuring Both Settings
+### Configuring both settings
 
 You can configure both settings independently:
 
@@ -252,7 +252,7 @@ await client.signAndExecuteTransaction({
 });
 ```
 
-## Withdrawing Funds from a Registry
+## Withdrawing funds from a registry
 
 If you've enabled registry-managed funds, you can withdraw accumulated coins:
 
@@ -275,14 +275,14 @@ const result = await client.signAndExecuteTransaction({
 console.log('Funds withdrawn!');
 ```
 
-**Important Notes:**
+**Important notes:**
 
 - Only the admin cap owner can withdraw funds
 - You must specify the coin type to withdraw
 - All coins of that type are withdrawn in one operation
 - The withdrawn coins are sent to the transaction sender
 
-### Withdrawing Multiple Coin Types
+### Withdrawing multiple coin types
 
 If your registry accumulates different coin types:
 
@@ -313,7 +313,7 @@ await client.signAndExecuteTransaction({
 });
 ```
 
-## Deleting Expired Payment Records
+## Deleting expired payment records
 
 After the expiration period, payment records can be deleted to reclaim storage fees:
 
@@ -335,14 +335,14 @@ const result = await client.signAndExecuteTransaction({
 console.log('Record deleted, storage rebate received');
 ```
 
-**Key Points:**
+**Key points:**
 
 - Records can only be deleted after expiration
 - Anyone can delete expired records (permissionless cleanup)
 - The deleter receives a small storage rebate
 - This incentivizes automatic cleanup of old records
 
-### Checking If a Record Can Be Deleted
+### Checking if a record can be deleted
 
 ```ts
 // Get the payment record
@@ -369,7 +369,7 @@ if (record) {
 }
 ```
 
-## Using Registry ID Directly
+## Using registry ID directly
 
 If you know the registry ID, you can use it instead of the name:
 
@@ -396,7 +396,7 @@ const record = await client.paymentKit.getPaymentRecord({
 });
 ```
 
-## Complete Registry Setup Example
+## Complete registry setup example
 
 Here's a complete workflow for setting up a custom registry:
 
@@ -502,28 +502,28 @@ if (paymentResult.$kind === 'FailedTransaction') {
 console.log('First payment processed:', paymentResult.Transaction.digest);
 ```
 
-## Best Practices
+## Best practices
 
-1. **Store Admin Caps Securely**: Treat your admin capability like private keys - they control your
+1. **Store admin caps securely**: Treat your admin capability like private keys - they control your
    registry
 
-2. **Use Descriptive Names**: Choose registry names that clearly identify their purpose (e.g.,
-   `acme-subscriptions`, `store-123-payments`)
+2. **Use descriptive names**: Choose registry names that clearly identify their purpose (for
+   example, `acme-subscriptions`, `store-123-payments`)
 
-3. **Set Appropriate Expiration**: Balance storage costs with verification needs
+3. **Set appropriate expiration**: Balance storage costs with verification needs
    - Short expiration = lower storage costs
    - Long expiration = longer verification period
 
-4. **Monitor Registry Growth**: Track the number of payment records to anticipate storage costs
+4. **Monitor registry growth**: Track the number of payment records to anticipate storage costs
 
-5. **Plan Fund Management**: Decide upfront whether to use registry-managed funds based on your
+5. **Plan fund management**: Decide upfront whether to use registry-managed funds based on your
    withdrawal patterns
 
-6. **Document Your Configuration**: Keep records of your registry settings for operational
+6. **Document your configuration**: Keep records of your registry settings for operational
    consistency
 
-7. **Test Thoroughly**: Always test registry operations on testnet before mainnet deployment
+7. **Test thoroughly**: Always test registry operations on Testnet before Mainnet deployment
 
-## Next Steps
+## Next steps
 
 - [SDK API Reference](./payment-kit-sdk) - Complete SDK API documentation

package/dist/seal/index.md

@@ -1,6 +1,6 @@
 # Seal SDK
 
-> Decentralized secrets management with threshold encryption on Sui
+> Decentralized secrets management with threshold encryption on Sui.
 
 > **Note:** This is a beta version of Seal. See https://github.com/MystenLabs/seal for more details.
 
@@ -32,7 +32,7 @@ const client = new SuiGrpcClient({
 );
 ```
 
-## Configuration Options
+## Configuration options
 
 The `seal()` function accepts the following options:
 
@@ -40,9 +40,9 @@ The `seal()` function accepts the following options:
 - **`verifyKeyServers`** (optional) - Whether to verify key server authenticity (default: `true`)
 - **`timeout`** (optional) - Timeout in milliseconds for network requests (default: `10000`)
 
-## Basic Usage
+## Basic usage
 
-### Encrypting Data
+### Encrypting data
 
 ```ts
 const data = new Uint8Array([1, 2, 3]);
@@ -55,7 +55,7 @@ const { encryptedObject } = await client.seal.encrypt({
 });
 ```
 
-### Decrypting Data
+### Decrypting data
 
 ```ts
 

package/dist/seal/llms-index.md

@@ -1,4 +1,4 @@
 # Seal
 > Use Seal, a decentralized secrets management service that secures your data using threshold encryption and on-chain access control.
 
-- [Seal SDK](..md): Decentralized secrets management with threshold encryption on Sui
+- [Seal SDK](..md): Decentralized secrets management with threshold encryption on Sui.

package/dist/slush-wallet/dapp.md

@@ -1,15 +1,15 @@
-# dApp Integration
+# App Integration
 
-> Connect your dApp to Slush Wallet
+> Connect your app to Slush Wallet using the Slush Wallet SDK and wallet standard.
 
 > **Note:** If you are using `dapp-kit`, you do not need to install any additional packages to integrate with
 > the Slush wallet. [Read how to integrate with dapp-kit.](/dapp-kit/legacy/slush)
 
-Using the Slush Wallet SDK, you can allow users to connect to the Slush wallet from your dApp. The
+Using the Slush Wallet SDK, you can allow users to connect to the Slush wallet from your app. The
 wallet is provided through the [Wallet Standard](https://docs.sui.io/standards/wallet-standard), and
 should appear automatically in your existing wallet connection UI.
 
-> The Slush Wallet SDK is only needed if you want to support the Slush web wallet in your dApp. If
+> The Slush Wallet SDK is only needed if you want to support the Slush web wallet in your app. If
 > you want to integrate with the Slush browser extension or native mobile wallet, you do not need to
 > install any additional packages - they will work automatically through the Wallet Standard.
 
@@ -21,7 +21,7 @@ your application's lifecycle.
 
 `registerSlushWallet` takes two arguments:
 
-- `name`: The name of your dApp. This will be shown to the user when they are asked to approve the
+- `name`: The name of your app. This is shown to the user when they are asked to approve the
   connection in Slush.
 - `options`: An optional object with the following properties:
   - `origin`: The origin of the Slush website. Defaults to `https://[TODO]`.
@@ -59,18 +59,18 @@ function SlushOnly() {
 }
 ```
 
-# Migration from Stashed Wallet -> Slush Wallet
+# Migration from Stashed Wallet to Slush Wallet
 
 If you're currently using `@mysten/zksend`'s `registerStashedWallet` directly, you should migrate to
 the `@mysten/slush-wallet` package to ensure compatibility with the new Slush experience.
 
-## 🚀 Installation
+## Installation
 
 ```bash
 pnpm install @mysten/slush-wallet
 ```
 
-## 🔁 Migration
+## Migration
 
 If you're using `registerStashedWallet`, switch to `registerSlushWallet`:
 
@@ -91,5 +91,5 @@ registerSlushWallet(...);
 If you're using dapp-kit, update to the latest dapp-kit version and change the `stashedWallet` prop
 on WalletProvider to `slushWallet`
 
-> Note: In the connect modal, users with the Slush Wallet extension installed will only see the
-> extension. If they don’t have it, the connection will default to the Slush web app.
+> In the connect modal, users with the Slush Wallet extension installed only see the extension. If
+> they don’t have it, the connection defaults to the Slush web app.