@sodax/wallet-sdk-core 2.0.0-rc.1 → 2.0.0-rc.2

package/ai-exported/AGENTS.md

@@ -0,0 +1,139 @@
+# AGENTS.md — `@sodax/wallet-sdk-core` AI Export
+
+You are a coding agent helping a developer **integrate** or **migrate** the `@sodax/wallet-sdk-core` package. This document is your entry point. Read this first, then route to the right sub-folder.
+
+The files in this `ai-exported/` directory are designed for AI consumption: short, table-heavy, self-contained recipes, and machine-checkable checklists. Human-readable narrative lives in each folder's `README.md`.
+
+---
+
+## What this package is
+
+`@sodax/wallet-sdk-core` is the **low-level** wallet layer of the SODAX stack — one provider class per chain family (9 in total: EVM, Solana, Sui, Bitcoin, Stellar, ICON, Injective, NEAR, Stacks). Each class accepts either a **private-key** config (server-side scripts, CI, Node) or a **browser-extension** config (consumer dApps with pre-built clients/wallet kits), signs transactions, and broadcasts them.
+
+It is **not** a React layer (that is `@sodax/wallet-sdk-react`) and **not** a hooks layer (that is `@sodax/dapp-kit`). Most React consumers never touch this package directly — they get a typed `IXxxWalletProvider` via `useWalletProvider(...)` and hand it to `@sodax/sdk` calls. Direct usage of `wallet-sdk-core` is the right choice for:
+
+- Backend / Node scripts (CI tests, indexers, bots).
+- Custom browser flows that don't use React.
+- Tests that need to sign with a deterministic key.
+
+---
+
+## Step 1 — Identify the task
+
+| User says... | Path | Start at |
+|---|---|---|
+| "sign a tx from a script", "instantiate `EvmWalletProvider`", "first time using this lib" | **integration** | `integration/ai-rules.md` |
+| "configure default gas", "set up `defaults`", "shallow merge surprised me" | **integration** | `integration/recipes/defaults-and-overrides.md` |
+| "where do I import `WalletClient` / `SuiClient` from", "avoid direct viem dep" | **integration** | `integration/recipes/library-exports.md` |
+| "upgrade from v1 / sodax-frontend", "bump from older RC" | **migration** | `migration/ai-rules.md` |
+| Deep import from `@sodax/wallet-sdk-core/wallet-providers/EvmWalletProvider` broke | **migration** | `migration/breaking-changes/folder-layout.md` |
+| Looking up a provider class or its config shape | direct | `integration/reference/provider-classes.md` |
+| Looking up the discriminated union shape per chain | direct | `integration/features/<chain>.md` |
+
+The package name **did not change** across versions — both v1 and v2 publish as `@sodax/wallet-sdk-core`. **All v1→v2 surface changes are additive** — class names, config-type names, and config shapes are identical. The only mechanical migration is replacing deep imports from v1's flat `wallet-providers/*.ts` layout with barrel imports.
+
+If a project does anything more than that at the wallet-sdk-core surface, you are almost certainly looking at an `@sodax/sdk` / `@sodax/types` migration, not this one. Route accordingly.
+
+---
+
+## Step 2 — Load the right context
+
+**For integration tasks:**
+
+1. `integration/ai-rules.md` — DO/DON'T + workflow + stop conditions
+2. `integration/architecture.md` — mental model (BaseWalletProvider, discriminants, defaults merge)
+3. `integration/quickstart.md` — copy-paste minimal example for the chain you need
+4. `integration/features/<chain>.md` — per-chain config table, methods, gotchas
+5. `integration/recipes/<task>.md` — task-specific guide (setup-private-key, bridge-to-sdk, …)
+6. `integration/reference/*.md` — full barrel exports, interfaces, chain support
+
+**For migration tasks:**
+
+1. `migration/ai-rules.md` — DO/DON'T + workflow. The headline: **v1 code drops in unchanged.** No mandatory edits at the wallet-sdk-core surface.
+2. `migration/README.md` — what (additively) changed, read order, TL;DR
+3. `migration/breaking-changes/*.md` — narrative WHY behind each additive shift (folder layout, base-class, defaults, library-exports)
+4. `migration/reference/*.md` — confirm no renames / no deletions exist
+5. `migration/recipes/<task>.md` — paired before/after for **optional** cleanup (adopt-defaults, adopt-library-exports)
+6. `migration/checklist.md` — verification loop
+
+---
+
+## Step 3 — Honor flow-specific stop conditions
+
+Each flow has its own list of conditions that **HARD STOP** code generation and require asking the user:
+
+- Migration stops → [`migration/ai-rules.md`](./migration/ai-rules.md) § "Stop conditions"
+- Integration stops → [`integration/ai-rules.md`](./integration/ai-rules.md) § "Stop conditions"
+
+Read the relevant list **before** applying any change. When stopping, quote the offending file/line and present the user with concrete options. Do **not** guess.
+
+Cross-flow signals (true regardless of flow):
+
+- User asks for a chain family not in [`integration/reference/chain-support.md`](./integration/reference/chain-support.md). Adding a new chain is a maintainer task, not user-app integration.
+- User wants to extend `BaseWalletProvider` directly. That is a maintainer-only path — confirm scope before writing code.
+
+---
+
+## Step 4 — Verification protocol
+
+After **every** code change you make:
+
+1. Run `pnpm checkTs` from the user's app root (or the package the change touched).
+2. If errors mention `@sodax/wallet-sdk-core`, look up the symbol in `integration/reference/` or `migration/reference/`.
+3. If a symbol isn't in any reference file, **stop and ask**. Do not invent migrations.
+4. After all errors resolve, mark the relevant items in `migration/checklist.md` (for migrations) or move to the next recipe.
+
+You are **done** when:
+- `pnpm checkTs` exits clean for the user's project.
+- All items in `migration/checklist.md` are checked (migration only).
+- The user has confirmed the changed flow works in their dev / test environment.
+
+---
+
+## Conventions in this directory
+
+- **Recipes are self-contained.** A recipe file in `recipes/` contains everything needed to apply the change — before/after code, steps, verification. Do not jump between files.
+- **Reference files are tables.** `reference/*.md` contains markdown tables and paired code blocks. Treat them as lookup, not narrative.
+- **Token budget**: Each file is sized to fit comfortably in your context. If you find yourself loading more than 3 files for a single task, you are probably doing it wrong — re-route via the table above.
+- **Single source of truth**: Behavioral / breaking-change *explanations* live only in `migration/breaking-changes/*.md`. Other files reference them but do not duplicate the prose.
+
+---
+
+## Quick symbol lookup
+
+If the user mentions a symbol you don't recognize, grep these files in order:
+
+```
+integration/reference/public-api.md       — every named export from the package
+integration/reference/provider-classes.md — provider class + config + interface mapping
+integration/reference/interfaces.md       — IXxxWalletProvider method signatures
+integration/reference/chain-support.md    — chain family → provider + dependencies
+migration/reference/renamed-symbols.md    — confirms zero renames between v1 and v2
+migration/reference/deleted-exports.md    — confirms zero deletions between v1 and v2
+migration/reference/added-fields.md       — additive `defaults` / `*WalletDefaults` / `*Policy` types
+```
+
+If still not found: the symbol may be **internal** (not exported from the package root) or **removed**. Ask the user to share the source file/line so you can decide.
+
+---
+
+## Package context
+
+- **Name**: `@sodax/wallet-sdk-core`
+- **Version target**: latest RC / stable on npm.
+- **Peer deps**: none — chain SDKs are direct dependencies and consumers can re-import types via `library-exports`.
+- **Install**: `pnpm add @sodax/wallet-sdk-core`
+- **Runtime**: Node ≥ 18 + browser (tsup `platform: 'neutral'`).
+- **Audience**: backend engineers, script authors, and React-layer authors building higher-level wrappers (`@sodax/wallet-sdk-react`).
+
+---
+
+## Pointers
+
+- [`integration/README.md`](./integration/README.md) — start here for new integrations: file index, recommended reading order, install snippet, dual-config overview.
+- [`migration/README.md`](./migration/README.md) — start here for upgrades: file index, reading order, cross-cutting checklist pointer.
+- [`integration/quickstart.md`](./integration/quickstart.md) — minimal end-to-end example per chain.
+- [`integration/architecture.md`](./integration/architecture.md) — mental model: `BaseWalletProvider`, defaults shallow merge, dual-config discriminants, `library-exports`.
+- [`integration/features/`](./integration/features/) — per-chain config table, methods, gotchas (one file per chain).
+- [`integration/reference/`](./integration/reference/) — public API, provider classes, interfaces, chain support, glossary.
+- [`migration/breaking-changes/`](./migration/breaking-changes/) — narrative WHY behind each version-to-version shift.

package/ai-exported/integration/README.md

@@ -0,0 +1,108 @@
+# Integration: First-time setup (Human-readable overview)
+
+This folder helps you integrate `@sodax/wallet-sdk-core` into a fresh project — most commonly a Node script, a backend service, or a custom non-React frontend. It is the **human-facing** entry point for new integrations. If you are a coding agent, read [`ai-rules.md`](./ai-rules.md) first.
+
+If you are upgrading from an older version of the package instead, see `../migration/`.
+
+---
+
+## What this package does
+
+`@sodax/wallet-sdk-core` is a **low-level multi-chain wallet provider layer**. For each of the 9 chain families that SODAX supports it ships **one provider class** that:
+
+- Accepts a **discriminated union config** — `PrivateKey*WalletConfig | BrowserExtension*WalletConfig`.
+- Extends a small `BaseWalletProvider` to merge per-call options over a typed `defaults` shape.
+- Implements the chain-specific `IXxxWalletProvider` interface from `@sodax/types`, so it can be passed straight into `@sodax/sdk` calls.
+
+It is intentionally framework-agnostic — Node ≥ 18, browser, edge runtimes are all supported (tsup `platform: 'neutral'`).
+
+| Chain family | Provider class | Underlying chain SDK |
+|---|---|---|
+| EVM (12 chains)        | `EvmWalletProvider`       | `viem` |
+| Solana                 | `SolanaWalletProvider`    | `@solana/web3.js` |
+| Sui                    | `SuiWalletProvider`       | `@mysten/sui` + `@mysten/wallet-standard` |
+| Bitcoin                | `BitcoinWalletProvider`   | `bitcoinjs-lib` (+ `ecpair`, `secp256k1`) |
+| Stellar                | `StellarWalletProvider`   | `@stellar/stellar-sdk` |
+| ICON                   | `IconWalletProvider`      | `icon-sdk-js` |
+| Injective              | `InjectiveWalletProvider` | `@injectivelabs/sdk-ts` + `@injectivelabs/wallet-core` |
+| NEAR                   | `NearWalletProvider`      | `near-api-js` + `@hot-labs/near-connect` |
+| Stacks                 | `StacksWalletProvider`    | `@stacks/transactions` + `@stacks/connect` |
+
+---
+
+## Recommended path (in order)
+
+If this is your first time using the package:
+
+1. [`architecture.md`](./architecture.md) — read once before any recipe. Explains `BaseWalletProvider`, the `defaults` shallow-merge model, dual-config discriminants, and the `library-exports` indirection. Picking the wrong config variant is the most common mistake — the mental model prevents it.
+2. [`quickstart.md`](./quickstart.md) — minimal end-to-end example for the chain you need. Copy, edit, run.
+3. [`features/<chain>.md`](./features/) — chain-specific config table, methods, and gotchas (one file per chain).
+4. Pick the right recipes:
+   - [`recipes/setup-private-key.md`](./recipes/setup-private-key.md) — server-side / CI flow.
+   - [`recipes/setup-browser-extension.md`](./recipes/setup-browser-extension.md) — consumer dApp flow.
+   - [`recipes/bridge-to-sdk.md`](./recipes/bridge-to-sdk.md) — hand off the provider to `@sodax/sdk` calls.
+   - [`recipes/defaults-and-overrides.md`](./recipes/defaults-and-overrides.md) — merge semantics for the `defaults` config.
+   - [`recipes/library-exports.md`](./recipes/library-exports.md) — re-importing upstream chain-SDK types without a direct dep.
+   - [`recipes/sign-and-broadcast.md`](./recipes/sign-and-broadcast.md) — typical send-transaction flow per chain.
+   - [`recipes/testing.md`](./recipes/testing.md) — mocking providers in unit tests.
+5. Reference docs (lookup as needed):
+   - [`reference/public-api.md`](./reference/public-api.md) — every named export from the package root.
+   - [`reference/provider-classes.md`](./reference/provider-classes.md) — provider × config × interface table.
+   - [`reference/interfaces.md`](./reference/interfaces.md) — `IXxxWalletProvider` method signatures.
+   - [`reference/chain-support.md`](./reference/chain-support.md) — chain family → spoke chain keys.
+   - [`reference/glossary.md`](./reference/glossary.md) — terms used across the docs.
+
+---
+
+## Install
+
+```bash
+pnpm add @sodax/wallet-sdk-core @sodax/types
+```
+
+Most consumers will also need `@sodax/sdk` (for the hub/spoke services that accept the wallet provider) and one or more chain SDKs (for browser-extension wallet objects). Re-export the types you need via `library-exports` — see [`recipes/library-exports.md`](./recipes/library-exports.md).
+
+---
+
+## Two configuration modes
+
+Every provider class supports **two** construction modes. Picking the wrong one is the most common integration mistake.
+
+| Mode | When to use | Discriminant style |
+|---|---|---|
+| **Private-key** | Node scripts, CI tests, indexers, bots — anywhere you possess the raw key | Either field presence (EVM, Solana, Sui, ICON, Injective, NEAR, Stacks) OR `type: 'PRIVATE_KEY'` (Bitcoin, Stellar) |
+| **Browser-extension** | Consumer dApps where a wallet extension provides a pre-built client / signer | Either field presence (different fields from PK variant) OR `type: 'BROWSER_EXTENSION'` (Bitcoin, Stellar) |
+
+For a chain-by-chain breakdown of the exact discriminant shape, see [`features/`](./features/) and [`architecture.md`](./architecture.md) § "Discriminant variants".
+
+---
+
+## Pair with `@sodax/sdk` and `@sodax/wallet-sdk-react`
+
+The most common stack:
+
+```
+@sodax/sdk              ← business logic (swaps, lending, staking, …)
+@sodax/wallet-sdk-react ← React layer that surfaces a typed IXxxWalletProvider via hooks
+@sodax/wallet-sdk-core  ← this package — concrete provider classes
+@sodax/types            ← shared type definitions
+```
+
+In a React dApp you usually consume this package **indirectly** — `useWalletProvider({ xChainId })` (from `@sodax/wallet-sdk-react`) returns a typed `IXxxWalletProvider` that comes from a `wallet-sdk-core` instance under the hood. You only construct provider classes from `wallet-sdk-core` directly when running scripts, tests, or non-React clients.
+
+---
+
+## Conventions worth knowing
+
+- **`defaults` is optional but powerful.** Every provider accepts a `defaults` config slice; per-call options shallow-merge over it. Use it to encode env-level fixed choices (RPC commitment, default gas, default memo) once.
+- **Shallow merge, not deep.** Nested objects in `defaults` are **replaced wholesale** by per-call options of the same key. See `src/utils/merge.ts` and [`recipes/defaults-and-overrides.md`](./recipes/defaults-and-overrides.md).
+- **`library-exports` removes upstream deps.** You can `import type { WalletClient } from '@sodax/wallet-sdk-core'` instead of taking a direct dep on `viem`. See [`recipes/library-exports.md`](./recipes/library-exports.md).
+- **The barrel is the source of truth.** Internal utilities (`shallowMerge`, helper functions) are **not** exported. If something isn't on `@sodax/wallet-sdk-core`'s root, do not deep-import it.
+- **No `as unknown as` casts.** The discriminated unions are precise — if TypeScript complains, your config is wrong, not the type.
+
+---
+
+## Getting help
+
+- API surface lookup: [`reference/`](./reference/).
+- Bug or missing feature: [open an issue](https://github.com/icon-project/sodax-sdks/issues).

package/ai-exported/integration/ai-rules.md

@@ -0,0 +1,141 @@
+# AI Rules — Fresh Integration
+
+You are integrating `@sodax/wallet-sdk-core` into a user's project for the first time. Follow this protocol exactly.
+
+---
+
+## Workflow (do these in order)
+
+### 1. Survey the project
+
+Before changing anything, gather context:
+
+```bash
+# Runtime — Node script? React dApp? Edge runtime?
+cat <user>/package.json | grep -E '"type|"main|"module'
+
+# Node version — must be >= 18
+cat <user>/.nvmrc 2>/dev/null
+node --version
+
+# Is the user already using @sodax/wallet-sdk-react?
+cat <user>/package.json | grep '"@sodax/wallet-sdk-react'
+
+# Are upstream chain SDKs already direct deps? (may indicate they don't yet know about library-exports)
+cat <user>/package.json | grep -E '"viem"|"@solana/web3.js"|"@mysten/sui"|"@stellar/stellar-sdk"|"@stacks/transactions"|"@injectivelabs"|"near-api-js"|"bitcoinjs-lib"|"icon-sdk-js"'
+```
+
+**If Node < 18**, stop and tell the user — this package requires Node ≥ 18.
+
+**If the user is already using `@sodax/wallet-sdk-react` in the same project**, ask whether they really need to construct providers directly. In a React app the answer is usually **no**: `useWalletProvider({ xChainId })` returns the typed provider for them. Direct construction is only correct for scripts, tests, or non-React clients.
+
+### 2. Pick the right mode
+
+For **each** chain the user wants to integrate, decide between:
+
+| Mode | When to pick | Stop and ask if... |
+|---|---|---|
+| **Private-key** | A Node script, CI runner, indexer, or test that legitimately possesses a raw key. | The user pastes a real-looking key in a frontend file. Never embed a private key in a browser bundle. |
+| **Browser-extension** | A dApp where a wallet extension (MetaMask, Phantom, Xverse, Hana, Freighter, Leather, …) provides the signing primitives. | The user has neither a key nor a wallet adapter on hand. They probably want `@sodax/wallet-sdk-react` instead. |
+
+Ask the user which mode applies **before** writing code. Default to **private-key** for `apps/node`-style scripts and **browser-extension** for `apps/web`-style dApps.
+
+### 3. Apply the matching recipe
+
+- Private-key flow → [`recipes/setup-private-key.md`](./recipes/setup-private-key.md).
+- Browser-extension flow → [`recipes/setup-browser-extension.md`](./recipes/setup-browser-extension.md).
+
+Each recipe is self-contained — install snippet, config, first method call, verification.
+
+### 4. Hand off to `@sodax/sdk` if needed
+
+If the user wants to swap / bridge / stake / lend / migrate, they need to pass the provider to `@sodax/sdk` calls. Apply [`recipes/bridge-to-sdk.md`](./recipes/bridge-to-sdk.md). Do not invent your own bridging pattern.
+
+### 5. Add advanced features as separate steps
+
+Only after the basic flow works should you add:
+
+- Default config slices ([`recipes/defaults-and-overrides.md`](./recipes/defaults-and-overrides.md))
+- Importing upstream chain types via `library-exports` ([`recipes/library-exports.md`](./recipes/library-exports.md))
+- Sign + broadcast flow for the chain ([`recipes/sign-and-broadcast.md`](./recipes/sign-and-broadcast.md))
+- Mocking providers in tests ([`recipes/testing.md`](./recipes/testing.md))
+
+Each is independent — apply only what the user asked for.
+
+---
+
+## DO
+
+- **DO** use the discriminated union types in your `import` statement so TypeScript narrows the config correctly:
+  ```ts
+  import { EvmWalletProvider, type EvmWalletConfig } from '@sodax/wallet-sdk-core';
+  ```
+- **DO** use chain key constants from `@sodax/types` (`ChainKeys.SONIC_MAINNET`, `ChainKeys.BSC_MAINNET`, …) instead of magic numbers / strings.
+- **DO** re-export upstream chain types via `library-exports` (`import type { WalletClient } from '@sodax/wallet-sdk-core'`) — keeps direct chain-SDK deps out of `package.json`.
+- **DO** pass an `IXxxWalletProvider` (the **interface** from `@sodax/types`), not the concrete class, to SDK calls. Interfaces are how the SDK stays decoupled from this package.
+- **DO** put RPC URLs, network selectors, default gas, etc. in the `defaults` config slice — one place, one source of truth.
+- **DO** consult [`features/<chain>.md`](./features/) for the chain you are integrating before writing the constructor call. Each chain has slightly different field names.
+
+---
+
+## DO NOT
+
+- **DO NOT** embed a private key in a frontend bundle. Browser-extension config exists for a reason.
+- **DO NOT** import from `@sodax/wallet-sdk-core/src/...` deep paths. Only the package root is public.
+- **DO NOT** deep-import the internal `shallowMerge` from `src/utils/merge.ts`. It is intentionally not exported.
+- **DO NOT** extend `BaseWalletProvider` in user code unless you are adding a brand-new chain to this package. That is a maintainer-only path.
+- **DO NOT** widen the discriminated union with a cast (e.g. `as EvmWalletConfig`). If TypeScript complains, your fields are wrong — fix the fields.
+- **DO NOT** mutate `defaults` after construction. Providers freeze the `defaults` reference; later mutations are silently ignored.
+- **DO NOT** mix discriminant styles for a chain. Bitcoin and Stellar **require** an uppercase `type: 'PRIVATE_KEY' | 'BROWSER_EXTENSION'`; every other chain uses **field presence**. See [`architecture.md`](./architecture.md) § "Discriminant variants".
+
+---
+
+## Stop conditions (defer to user)
+
+| Signal | Why stop |
+|---|---|
+| User asks for a chain family not in [chain support](./reference/chain-support.md) | Adding a new chain is a maintainer task, not user-app integration. |
+| User wants to extend `BaseWalletProvider` directly | Maintainer-only path. Confirm scope first. |
+| User wants to deep-merge `defaults` with per-call options | Not supported — merge is **shallow** by design. See [`recipes/defaults-and-overrides.md`](./recipes/defaults-and-overrides.md). If the user really needs deep merge, they must combine before passing. |
+| User wants to inject a custom `Transport` / `Connection` / `SuiClient` in private-key mode | Some chains expose this via `defaults`; others don't. Check the chain's [feature file](./features/) first. |
+| User wants to use a wallet brand the chain SDK does not support | Out of scope — wallet brand support lives in the upstream chain SDK / kit. |
+| User is in a React app and wants to construct providers in components | Almost always wrong. Direct user to `@sodax/wallet-sdk-react`'s `useWalletProvider` hook. |
+| User asks "how do I sign with X without a key and without an extension" | They probably want a custom signer — this package does not currently model that. Flag as out of scope. |
+
+When stopping, **quote the file/line** of the offending code and present the user with concrete options.
+
+---
+
+## Verification protocol (after every recipe)
+
+```bash
+# 1. Type check passes
+pnpm checkTs
+
+# 2. No deep imports
+grep -rn "@sodax/wallet-sdk-core/" <user-src> | grep -v "from '@sodax/wallet-sdk-core'"
+# expect empty — only barrel imports allowed
+
+# 3. No direct upstream chain-SDK imports for types that library-exports provides
+grep -rn "from 'viem'" <user-src> | grep -E "WalletClient|PublicClient|TransactionReceipt"
+# if any match, suggest re-importing via @sodax/wallet-sdk-core
+
+# 4. Sample call works
+# (manual — run a one-shot sign + broadcast on testnet)
+```
+
+If steps 1–3 pass and the user confirms step 4, the recipe is done.
+
+---
+
+## Done criteria
+
+The integration is complete when:
+
+- [ ] `pnpm checkTs` exits clean.
+- [ ] The user has at least one provider instance constructed via the correct discriminated union variant.
+- [ ] Types are imported from `@sodax/wallet-sdk-core` (and `@sodax/types`) only — no deep paths.
+- [ ] If using `@sodax/sdk`: the provider is passed via the `IXxxWalletProvider` interface, not the concrete class.
+- [ ] A sign + broadcast (or get-address) call has succeeded against testnet or a local mock.
+
+Do not declare integration done before all of the above are true.

package/ai-exported/integration/architecture.md

@@ -0,0 +1,212 @@
+# Architecture — Mental Model
+
+This file explains **why** `@sodax/wallet-sdk-core` is shaped the way it is. Read it once before applying recipes — knowing the model lets you handle ambiguous user code without guessing.
+
+If you are looking for "how do I do X", go to [`recipes/`](./recipes/) or [`features/`](./features/). This file is purely conceptual.
+
+---
+
+## The shape of the package
+
+`@sodax/wallet-sdk-core` is a **uniform low-level wallet layer over heterogeneous chain SDKs**. For each of the 9 chain families that SODAX supports, the package ships:
+
+1. A `*WalletProvider` **class** that implements a chain-specific interface (`IEvmWalletProvider`, `ISolanaWalletProvider`, …) imported from `@sodax/types`.
+2. A discriminated-union **config type** (`*WalletConfig = PrivateKey* | BrowserExtension*`).
+3. A `*WalletDefaults` type — the per-method default option shape merged into each call.
+
+Each provider class extends a small abstract `BaseWalletProvider<TDefaults>`. That base holds the `defaults` reference and exposes two helpers:
+
+- `mergePolicy(key, options)` — shallow-merges per-call options over `defaults[key]`. Used when defaults are grouped per method (e.g. `defaults.sendTransaction`).
+- `mergeDefaults(options)` — shallow-merges per-call options over the entire flat `defaults`. Used when defaults are not grouped.
+
+Subclasses do three things on top:
+
+1. Declare a `chainType` literal (`'EVM' as const`, `'BITCOIN' as const`, …).
+2. Discriminate the config and initialize chain-specific state (viem client, Solana `Connection`, `SuiClient`, …).
+3. Implement the chain-specific interface methods (`sendTransaction`, `signTransaction`, …).
+
+Consumers only ever see the public surface: construct the class with one of the union variants, call its methods, and hand the instance to `@sodax/sdk` via its `IXxxWalletProvider` interface.
+
+---
+
+## File-system tour
+
+```
+src/
+├── index.ts                          # Barrel: re-exports wallet-providers + types
+├── types/
+│   ├── index.ts                      # Re-exports library-exports
+│   └── library-exports.ts            # Re-exported types (and a few enums) from upstream chain SDKs
+├── utils/                            # Internal — shallowMerge; NOT re-exported
+│   ├── index.ts
+│   ├── merge.ts
+│   └── merge.test.ts
+└── wallet-providers/
+    ├── index.ts                      # Barrel: re-exports every provider folder
+    ├── BaseWalletProvider.ts         # Abstract base class
+    ├── evm/
+    │   ├── EvmWalletProvider.ts
+    │   ├── EvmWalletProvider.test.ts
+    │   ├── types.ts
+    │   └── index.ts
+    ├── solana/   { …same shape… }
+    ├── sui/      { …same shape… }
+    ├── bitcoin/  { …same shape… }
+    ├── stellar/  { …same shape… }
+    ├── icon/     { …same shape… }
+    ├── injective/{ …same shape… }
+    ├── near/     { …same shape… }
+    └── stacks/   { …same shape… }
+```
+
+Three things to internalize:
+
+1. **The package root is the only public surface.** `src/utils/*` is internal — `shallowMerge` etc. are deliberately not re-exported.
+2. **Each chain is folder-isolated.** Adding a new chain means creating a folder under `src/wallet-providers/<chain>/` and listing it in `wallet-providers/index.ts`. Nothing else changes.
+3. **`types/library-exports.ts` is the indirection point** between upstream chain SDKs and consumers. Re-exporting from here means consumer apps don't need direct deps on `viem`, `@mysten/sui`, etc. for type-only usage.
+
+---
+
+## `BaseWalletProvider` and the `defaults` model
+
+```ts
+abstract class BaseWalletProvider<TDefaults extends object> {
+  protected readonly defaults: TDefaults;
+
+  constructor(defaults: TDefaults | undefined) {
+    this.defaults = (defaults ?? {}) as TDefaults;
+  }
+
+  abstract getWalletAddress(): Promise<string>;
+
+  protected mergePolicy<K extends keyof TDefaults>(key: K, options?: …): … { /* shallowMerge */ }
+  protected mergeDefaults(options?: Partial<TDefaults>): TDefaults { /* shallowMerge */ }
+}
+```
+
+Three rules govern the `defaults` model:
+
+1. **Every field of `TDefaults` is optional.** The constructor falls back to `{}` if the consumer omits `defaults` entirely. Required fields would silently arrive as `undefined` at runtime without TypeScript catching it — see the JSDoc comment in `BaseWalletProvider.ts`.
+2. **Merge is shallow.** Top-level keys merge; nested objects are **replaced wholesale**. If `defaults.sendTransaction = { gas: 3_000_000n, nonce: 0 }` and the caller passes `{ gas: 5_000_000n }`, the merged policy is `{ gas: 5_000_000n }` — `nonce` is dropped. See `src/utils/merge.ts`. The behaviour is intentional: deep merge would silently smuggle stale fields across call sites.
+3. **`undefined` layers and `undefined` values are skipped.** Passing `{ field: undefined }` does **not** override an earlier layer — the merge treats `undefined` as "no opinion".
+
+Two helpers exist because chains group their defaults differently:
+
+- **Per-method grouping** — `mergePolicy('sendTransaction', options)` looks up `defaults.sendTransaction` and merges `options` over it. Used by EVM (`sendTransaction`, `waitForTransactionReceipt`), Sui (`signAndExecuteTxn`, `getCoins`).
+- **Flat grouping** — `mergeDefaults(options)` merges `options` over the whole `defaults` object. Used by chains whose `defaults` is a flat record (Bitcoin's `{ defaultFinalize }`, Stellar's `{ pollInterval, pollTimeout, networkPassphrase }`).
+
+For a concrete worked example see [`recipes/defaults-and-overrides.md`](./recipes/defaults-and-overrides.md).
+
+---
+
+## Discriminant variants
+
+Every chain supports two construction modes — but the discriminant **looks different per chain**. The rule of thumb:
+
+| Discriminant style | Chains | Example |
+|---|---|---|
+| **Field presence** (no `type` field) | EVM, Solana, Sui, ICON, Injective, NEAR, Stacks | EVM: `privateKey + chainId` → private-key. `walletClient + publicClient` → browser-extension. |
+| **Explicit uppercase `type`** | Bitcoin, Stellar | `{ type: 'PRIVATE_KEY', … }` vs `{ type: 'BROWSER_EXTENSION', … }` |
+
+Why the inconsistency: the field-presence form is shorter for the common case but only works when the two variants share **zero** required-field overlap. Bitcoin and Stellar have shared required fields (`network`, `walletsKit` shapes that overlap with PK fields) that would make field presence ambiguous, so they use explicit `type`.
+
+Two more wrinkles to know about:
+
+- **Sui uses `mnemonics`, not `privateKey`.** The library derives an Ed25519 keypair from the mnemonic phrase. There is no raw-secret-key option.
+- **Injective uses a nested `secret` object.** Because Injective can be constructed from **either** a private key **or** a BIP-39 mnemonic, the private-key variant nests credentials under `secret: { privateKey } | { mnemonics }` instead of placing them at the top level. The type is named `SecretInjectiveWalletConfig` (not `PrivateKey*`) to reflect this.
+
+For chain-by-chain breakdowns see [`features/`](./features/).
+
+---
+
+## `library-exports` — the upstream-SDK indirection
+
+`src/types/library-exports.ts` re-exports a curated set of types (and a few runtime values) from each upstream chain SDK:
+
+```ts
+// viem types
+export type { Account, Address, Chain, Transport, PublicClient, WalletClient,
+              HttpTransportConfig, PublicClientConfig, WalletClientConfig,
+              SendTransactionParameters, WaitForTransactionReceiptParameters,
+              TransactionReceipt } from 'viem';
+
+// Sui types
+export type { SuiTransactionBlockResponseOptions } from '@mysten/sui/client';
+export type { Transaction, TransactionArgument } from '@mysten/sui/transactions';
+export type { SuiWalletFeatures, WalletAccount, WalletWithFeatures } from '@mysten/wallet-standard';
+
+// Solana types
+export type { Commitment, ConnectionConfig, SendOptions } from '@solana/web3.js';
+
+// Injective types
+export type { Network } from '@injectivelabs/networks';
+export type { ChainId, EvmChainId } from '@injectivelabs/ts-types';
+export type { MsgBroadcaster } from '@injectivelabs/wallet-core';
+
+// Stellar (also re-exports the `Networks` runtime value)
+export { Networks } from '@stellar/stellar-sdk';
+
+// Stacks (also re-exports the `PostConditionMode` enum)
+export { PostConditionMode } from '@stacks/transactions';
+export type { ClarityValue, PostConditionModeName } from '@stacks/transactions';
+export type { StacksNetwork } from '@stacks/network';
+export type { StacksProvider } from '@stacks/connect';
+
+// Near
+export type { KeyPairString } from 'near-api-js';
+export type { NearConnector } from '@hot-labs/near-connect';
+
+// Bitcoin
+export type { Network as BitcoinJsNetwork } from 'bitcoinjs-lib/src/networks.js';
+```
+
+Consumers can import the types they need directly from `@sodax/wallet-sdk-core` instead of adding `viem`, `@mysten/sui`, etc. to their `package.json`:
+
+```ts
+import type { WalletClient, PublicClient, TransactionReceipt } from '@sodax/wallet-sdk-core';
+```
+
+Note the file name: `library-exports`, not `library-types`. It deliberately re-exports a small number of **runtime** values (`Networks`, `PostConditionMode`) — hence the broader name.
+
+For the typical reasons to use it (and when not to), see [`recipes/library-exports.md`](./recipes/library-exports.md).
+
+---
+
+## The `IXxxWalletProvider` interface — your handoff to `@sodax/sdk`
+
+Each provider class implements a chain-specific interface from `@sodax/types`:
+
+```ts
+class EvmWalletProvider extends BaseWalletProvider<EvmWalletDefaults> implements IEvmWalletProvider { … }
+class BitcoinWalletProvider extends BaseWalletProvider<BitcoinWalletDefaults> implements IBitcoinWalletProvider { … }
+// …and so on
+```
+
+When you call `@sodax/sdk` methods, the SDK expects the **interface**, not the concrete class:
+
+```ts
+import type { IEvmWalletProvider } from '@sodax/types';
+
+async function deposit(evmProvider: IEvmWalletProvider) { /* … */ }
+
+const evm = new EvmWalletProvider({ … });
+await deposit(evm);  // ✅ EvmWalletProvider implements IEvmWalletProvider
+```
+
+This indirection is how the SDK stays decoupled from `wallet-sdk-core`. In a React app, `useWalletProvider({ xChainId })` from `@sodax/wallet-sdk-react` returns the interface directly — the React layer constructs the concrete class internally.
+
+For the full interface signatures, see [`reference/interfaces.md`](./reference/interfaces.md).
+
+---
+
+## Things that look weird until you know why
+
+- **`InjectiveWalletConfig` is `BrowserExtensionInjectiveWalletConfig | SecretInjectiveWalletConfig`** — note the `Secret*` (not `PrivateKey*`) name. It also accepts mnemonics, hence the broader name. See [`features/injective.md`](./features/injective.md).
+- **EVM in browser-extension mode ignores `defaults.transport`, `defaults.publicClient`, and `defaults.walletClient`.** Because the consumer supplied pre-built clients, these defaults are no-ops — the provider logs a one-time `console.warn`. Pass them only in private-key mode. See `EvmWalletProvider.ts`.
+- **HyperEVM is defined inside this package.** `viem/chains` does not ship a HyperEVM config, so `wallet-providers/evm/EvmWalletProvider.ts` exports a `hyper` chain object via `defineChain`. You shouldn't need to import it directly — `getEvmViemChain(ChainKeys.HYPEREVM_MAINNET)` returns it.
+- **`getEvmViemChain(key)` is exhaustively typed.** The default branch is a `never`-assertion — if `@sodax/types` adds a new `EvmChainKey` value, this function fails to typecheck until the case is added. That's by design.
+- **Sui browser-extension mode requires THREE objects** — `client`, `wallet`, and `account`. Many wallet adapters expose the first two but not the third. See [`features/sui.md`](./features/sui.md).
+- **Stellar requires `rpcUrl` in both modes** (technically optional, but defaults to a public RPC). Use a private RPC for production.
+- **Bitcoin in private-key mode also takes an optional `addressType`** (P2WPKH / P2TR / …). Browser-extension mode infers it from the wallet kit.
+
+Everything else is covered by [`features/`](./features/) on a per-chain basis.

package/ai-exported/integration/features/README.md

@@ -0,0 +1,22 @@
+# Per-chain feature docs
+
+One file per chain family. Each file documents:
+
+- The provider class and the discriminated union of accepted configs.
+- The `*Defaults` shape.
+- The methods exposed on the provider (and how they merge defaults).
+- Common gotchas specific to the chain.
+
+| Chain family | Provider | Discriminant style | Underlying SDK |
+|---|---|---|---|
+| [EVM](./evm.md)           | `EvmWalletProvider`       | Field presence (no `type`) | `viem` |
+| [Solana](./solana.md)     | `SolanaWalletProvider`    | Field presence | `@solana/web3.js` |
+| [Sui](./sui.md)           | `SuiWalletProvider`       | Field presence (uses `mnemonics`) | `@mysten/sui` + `@mysten/wallet-standard` |
+| [Bitcoin](./bitcoin.md)   | `BitcoinWalletProvider`   | Explicit `type` | `bitcoinjs-lib`, `ecpair`, `secp256k1` |
+| [Stellar](./stellar.md)   | `StellarWalletProvider`   | Explicit `type` | `@stellar/stellar-sdk` |
+| [ICON](./icon.md)         | `IconWalletProvider`      | Field presence | `icon-sdk-js` |
+| [Injective](./injective.md)| `InjectiveWalletProvider` | Field presence (uses `secret` wrapper) | `@injectivelabs/sdk-ts`, `@injectivelabs/wallet-core` |
+| [NEAR](./near.md)         | `NearWalletProvider`      | Field presence | `near-api-js` + `@hot-labs/near-connect` |
+| [Stacks](./stacks.md)     | `StacksWalletProvider`    | Field presence | `@stacks/transactions`, `@stacks/connect` |
+
+For the mental model behind these tables — why discriminants differ, how `defaults` merges, what `library-exports` re-exports — see [`../architecture.md`](../architecture.md).