@idosgames/wallet 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 iDos Games
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,254 @@
+# @idosgames/wallet
+
+The on-chain half of the iDosGames blockchain flow. `@idosgames/core`'s
+`client.blockchain` is deliberately **report-only**: it verifies deposits and
+issues signed withdrawals but never signs or broadcasts a transaction. This
+package is the missing piece — it **connects browser & mobile wallets** and
+runs the exact RewardPool contract calls, threading them through the
+`request → submit → confirm` / `approve → deposit → report` lifecycle so a
+player can move tokens and NFTs in and out of the game.
+
+- **EVM** — [wagmi](https://wagmi.sh) + [viem](https://viem.sh) +
+  WalletConnect. Browser (MetaMask / any injected wallet) and mobile (via
+  WalletConnect) are both first-class.
+- **Solana** — `@solana/wallet-adapter` for connection; the on-chain
+  instruction building is delegated to a small `SolanaProgramAdapter` you
+  implement with your program's IDL (see [Solana](#solana)).
+
+Everything stays **server-authoritative**: the bridge only submits what the
+backend signed/verified and mirrors the confirmed result into the core cache.
+
+## Install
+
+```bash
+npm i @idosgames/wallet @idosgames/core
+# EVM peer deps:
+npm i wagmi viem @tanstack/react-query
+# Solana peer deps (only if you support Solana networks):
+npm i @solana/web3.js @solana/wallet-adapter-react @solana/wallet-adapter-base @solana/wallet-adapter-wallets
+```
+
+Two entry points:
+
+- `@idosgames/wallet` — framework-agnostic bridge functions (viem +
+  `@solana/web3.js` only). Use these directly if you're not on React.
+- `@idosgames/wallet/react` — wagmi/React hooks + providers. Everything below
+  uses these.
+
+## Operation category
+
+The updated RewardPool contract tags each operation with a string **category**
+(default `"game_topup"`; `"community_reward"` is the other known value).
+Deposits read it back from the on-chain tx; withdrawals sign it into the hash,
+so it must be submitted on-chain verbatim — the bridge handles that. Pass a
+category to any deposit/withdraw call, or omit it for `"game_topup"`. Constants
+live in `@idosgames/core` as `BlockchainOperationCategory`.
+
+## EVM
+
+### 1. Set up the provider
+
+`createEvmWalletConfig` builds a wagmi config wired for both browser and mobile
+wallets. Wrap your app with `IDosGamesWalletProvider` (WagmiProvider +
+react-query) once.
+
+```tsx
+import { polygon } from "viem/chains";
+import {
+  createEvmWalletConfig,
+  IDosGamesWalletProvider,
+} from "@idosgames/wallet/react";
+
+const wagmiConfig = createEvmWalletConfig({
+  chains: [polygon], // match the EVM networks in your title's blockchain config
+  walletConnectProjectId: "<your walletconnect cloud id>", // enables MOBILE wallets
+  appName: "My Game",
+});
+
+export function Root() {
+  return (
+    <IDosGamesWalletProvider wagmiConfig={wagmiConfig}>
+      <App />
+    </IDosGamesWalletProvider>
+  );
+}
+```
+
+Connect/disconnect with wagmi's own hooks (`useConnect`, `useAccount`,
+`useDisconnect`) — the `injected()` connector covers MetaMask & browser
+extensions, `walletConnect()` opens the QR/deep-link modal for phones.
+
+### 2. Deposit a token
+
+`useEvmBridge(client, titleID)` binds the connected wallet to the four flows.
+Amounts are **raw on-chain units** — scale with viem's `parseUnits`.
+
+```tsx
+import { parseUnits } from "viem";
+import { useEvmBridge } from "@idosgames/wallet/react";
+import type { BlockchainNetworkDefinition } from "@idosgames/core";
+
+function DepositButton({ client, network, usdtAddress }) {
+  const bridge = useEvmBridge(client, "my-title-id");
+
+  async function deposit() {
+    // approve → depositERC20(token, amount, userID, titleID, category) → report to backend
+    const res = await bridge.depositToken({
+      network, // BlockchainNetworkDefinition from getDefinitions()
+      tokenAddress: usdtAddress, // ERC-20 contract
+      amount: parseUnits("25", 6), // 25 USDT (6 decimals) as raw units
+      // category defaults to "game_topup"
+    });
+    if (!res.ok) return alert(`${res.stage}: ${res.error}`);
+    // core cache balance is already updated; res.data is DepositTokenResponse
+  }
+
+  return (
+    <button disabled={!bridge.connected} onClick={deposit}>
+      Deposit 25 USDT
+    </button>
+  );
+}
+```
+
+### 3. Withdraw a token
+
+```tsx
+const res = await bridge.withdrawToken({
+  currencyID: "usdt",
+  networkID: "polygon",
+  walletAddress: bridge.account!, // destination — usually the connected wallet
+  amount: "25.00", // human decimal; server scales & signs raw units
+});
+if (!res.ok) {
+  // If it failed AFTER the debit, res.titleTransactionID is set — recover with
+  // retryWithdrawal (while Pending) or confirmWithdrawal, NEVER a fresh request.
+  console.error(res.stage, res.error, res.titleTransactionID);
+}
+```
+
+The bridge runs `requestTokenWithdrawal` (debits in-game) → `withdrawERC20`
+on-chain → `confirmWithdrawal`. A `BridgeFailure` tells you exactly where it
+stopped via `stage` (`request` / `withdraw-onchain` / `confirm`) so you can
+recover correctly — see [Failure & recovery](#failure--recovery).
+
+### 4. NFTs
+
+```tsx
+// Deposit: safeTransferFrom(account, pool, id, amount, abi.encode(userID,titleID,category))
+await bridge.depositNft({
+  network,
+  nftContractAddress,
+  tokenId: 42n,
+  amount: 1n,
+});
+
+// Withdraw: requestNFTWithdrawal → withdrawERC1155 → confirmWithdrawal
+await bridge.withdrawNft({
+  itemID,
+  networkID: "polygon",
+  walletAddress: bridge.account!,
+  amount: "1",
+});
+```
+
+## Solana
+
+The Solana RewardPool is a custom program whose instruction/account layout
+isn't in this SDK — so you provide a `SolanaProgramAdapter` (two methods:
+`depositSpl` and `submitWithdrawal`) built with your program's IDL /
+`@solana/web3.js` and the connected wallet from `@solana/wallet-adapter-react`.
+The SDK-side orchestration is identical to EVM.
+
+```tsx
+import {
+  SolanaWalletBridgeProvider,
+  useSolanaBridge,
+} from "@idosgames/wallet/react";
+import { PhantomWalletAdapter } from "@solana/wallet-adapter-wallets";
+import type { SolanaProgramAdapter } from "@idosgames/wallet";
+
+// Wrap (alongside IDosGamesWalletProvider if you also support EVM):
+<SolanaWalletBridgeProvider
+  endpoint="https://api.mainnet-beta.solana.com"
+  wallets={[new PhantomWalletAdapter()]}
+>
+  <App />
+</SolanaWalletBridgeProvider>;
+
+// Your program integration:
+const adapter: SolanaProgramAdapter = {
+  async depositSpl({ mint, amountRaw, userID, titleID, category }) {
+    /* build + send the DepositSpl tx with your IDL; return the signature */
+  },
+  async submitWithdrawal(sig) {
+    /* build + send withdraw_spl with the ed25519 sig-verify ix; return the signature */
+  },
+};
+
+function Screen({ client }) {
+  const bridge = useSolanaBridge(client, "my-title-id", adapter);
+  // bridge.depositToken({ network, mint, amountRaw }) / bridge.withdrawToken({ currencyID, networkID, amount })
+}
+```
+
+## Failure & recovery
+
+Every bridge call resolves to a `BridgeResult<T>`:
+
+```ts
+type BridgeResult<T> =
+  | { ok: true; onChainTxHash: string; data: T }
+  | {
+      ok: false;
+      stage: BridgeStage; // where it stopped
+      error: string;
+      onChainTxHash?: string; // set if the asset-moving tx already landed
+      titleTransactionID?: string; // set if a withdrawal already debited in-game
+    };
+```
+
+Recovery rules (the bridge never double-charges, but you drive the retry):
+
+- **`stage: "approve" | "deposit-onchain"`** — nothing was reported; safe to
+  retry the whole deposit.
+- **`stage: "report"`** — the on-chain tx (`onChainTxHash`) landed but the
+  backend didn't credit it; retry `client.blockchain.depositToken/depositNFT`
+  with that hash.
+- **`stage: "withdraw-onchain"` with a `titleTransactionID`** — the withdrawal
+  was already debited in-game but not submitted on-chain. Get a fresh signature
+  with `client.blockchain.retryWithdrawal(titleTransactionID)` (while `Pending`)
+  and submit it with `submitEvmTokenWithdrawal` / `submitEvmNftWithdrawal` —
+  **never** call `withdrawToken` again (that debits twice).
+- **`stage: "confirm"` with `onChainTxHash` + `titleTransactionID`** — the tx
+  landed but the backend confirm didn't stick; retry
+  `client.blockchain.confirmWithdrawal(titleTransactionID, onChainTxHash)`.
+
+## Framework-agnostic core
+
+Not on React? Import the same flows from `@idosgames/wallet` and pass viem
+clients yourself:
+
+```ts
+import { depositTokenEvm, withdrawTokenEvm } from "@idosgames/wallet";
+
+const clients = { publicClient, walletClient, account }; // your viem clients
+await depositTokenEvm({
+  client,
+  clients,
+  network,
+  tokenAddress,
+  amount,
+  titleID,
+});
+```
+
+## Notes
+
+- The RewardPool ABI here mirrors the backend's `RewardPoolEvmV2` signing
+  (field order/names of `withdrawERC20`/`withdrawERC1155`/`depositERC20` must
+  match, or signatures fail on-chain).
+- After a deposit/withdrawal the core **balance** cache is fresh, but
+  `client.data.user.state.Blockchain` (pending list, stats) is not — call
+  `client.blockchain.getUserState()` to refresh it. See the `blockchain-system`
+  skill for the full server-side surface, withdrawal gates, and gotchas.

package/dist/bridge-BCxf6AHE.d.cts

@@ -0,0 +1,269 @@
+import { PublicClient, WalletClient, Address, Abi, ContractFunctionName, ContractFunctionArgs, Hex } from 'viem';
+import { IDosGamesClient, BlockchainNetworkDefinition, DepositNFTResponse, DepositTokenResponse, WithdrawalSignatureResponse, NFTWithdrawalResponse, TokenWithdrawalResponse, SolanaWithdrawalSignature } from '@idosgames/core';
+
+/**
+ * Where a multi-step bridge flow stopped. Deposits run approve → deposit-onchain → report;
+ * withdrawals run request → withdraw-onchain → confirm. Knowing the stage lets a UI recover
+ * correctly (e.g. a failed `withdraw-onchain` after a successful `request` means the asset is
+ * already debited — offer `retryWithdrawal`, never a fresh request that would debit twice).
+ */
+type BridgeStage = "approve" | "deposit-onchain" | "report" | "request" | "withdraw-onchain" | "confirm";
+interface BridgeSuccess<T> {
+    ok: true;
+    /** Hash/signature of the on-chain transaction that moved the asset (EVM hex or Solana base58). */
+    onChainTxHash: string;
+    /** The core SDK response that finalized the operation server-side. */
+    data: T;
+}
+interface BridgeFailure {
+    ok: false;
+    stage: BridgeStage;
+    error: string;
+    /**
+     * Set when the asset-moving on-chain tx already landed but a later step failed — the caller can
+     * finish the flow with this hash (e.g. re-call `confirmWithdrawal`) instead of restarting.
+     */
+    onChainTxHash?: string;
+    /**
+     * Set for a withdrawal whose server-side `request` already succeeded (and already debited the
+     * player) but whose on-chain/confirm leg failed. Recover with `client.blockchain.retryWithdrawal`
+     * (before ExpiresAt) or `confirmWithdrawal` (if the tx actually landed) — NOT a fresh request.
+     */
+    titleTransactionID?: string;
+}
+type BridgeResult<T> = BridgeSuccess<T> | BridgeFailure;
+/** Normalizes a thrown value (viem error, plain Error, or unknown) into a short human string. */
+declare function toErrorMessage(e: unknown): string;
+declare function bridgeFail(stage: BridgeStage, error: string, extra?: {
+    onChainTxHash?: string;
+    titleTransactionID?: string;
+}): BridgeFailure;
+/**
+ * Where a wallet-login flow stopped. `challenge` = fetching the message to sign; `sign` = the
+ * wallet signing it (user may reject); `login` = exchanging the signature for a session. Unlike
+ * a bridge flow there is no on-chain transaction — this is an off-chain proof of ownership.
+ */
+type WalletLoginStage = "challenge" | "sign" | "login";
+interface WalletLoginSuccess<T> {
+    ok: true;
+    /** The core SDK result of the successful login (the fresh ClientState). */
+    data: T;
+}
+interface WalletLoginFailure {
+    ok: false;
+    stage: WalletLoginStage;
+    error: string;
+}
+type WalletLoginResult<T> = WalletLoginSuccess<T> | WalletLoginFailure;
+declare function walletLoginFail(stage: WalletLoginStage, error: string): WalletLoginFailure;
+
+/**
+ * The viem clients + signing account the EVM bridge needs. wagmi supplies all three:
+ * `usePublicClient()`, `useWalletClient().data`, and `useAccount().address`. Kept as plain viem
+ * types so the framework-agnostic core never imports wagmi/React.
+ */
+interface EvmBridgeClients {
+    publicClient: PublicClient;
+    walletClient: WalletClient;
+    /** The connected wallet address that signs and pays for the transactions. */
+    account: Address;
+}
+/**
+ * Sends a contract write and waits for its receipt, returning the tx hash. Throws if the
+ * transaction reverts on-chain (so callers can attribute the failure to the on-chain stage).
+ */
+declare function writeAndWait<const TAbi extends Abi, TFunctionName extends ContractFunctionName<TAbi, "nonpayable" | "payable">>(clients: EvmBridgeClients, request: {
+    address: Address;
+    abi: TAbi;
+    functionName: TFunctionName;
+    args: ContractFunctionArgs<TAbi, "nonpayable" | "payable", TFunctionName>;
+    value?: bigint;
+}): Promise<Hex>;
+
+/**
+ * Ensures the RewardPool is allowed to pull at least `amount` of an ERC-20 from `account`.
+ * Reads the current allowance and only sends an `approve` when it's short. Returns the approve
+ * tx hash if one was sent, or null when the existing allowance already covered the amount.
+ */
+declare function ensureErc20Allowance(clients: EvmBridgeClients, tokenAddress: Address, spender: Address, amount: bigint): Promise<Hex | null>;
+interface DepositTokenEvmParams {
+    client: IDosGamesClient;
+    clients: EvmBridgeClients;
+    network: BlockchainNetworkDefinition;
+    /** ERC-20 contract of the token being deposited (the RewardPool splits/credits it in-game). */
+    tokenAddress: Address;
+    /** Raw on-chain amount, already scaled by the token's decimals (use viem `parseUnits`). */
+    amount: bigint;
+    /** The title the client was created for (not exposed on the client — pass it through). */
+    titleID: string;
+    /** Operation kind; defaults to "game_topup" server-side. Deposits echo it into the tx. */
+    category?: string;
+}
+/**
+ * Full EVM token-deposit flow: approve (if needed) → `depositERC20(token, amount, userID,
+ * titleID, category)` on the RewardPool → report the tx hash to the backend so it verifies the
+ * transfer and credits the in-game crypto balance. On success the core cache balance is already
+ * updated by `client.blockchain.depositToken`.
+ */
+declare function depositTokenEvm(params: DepositTokenEvmParams): Promise<BridgeResult<DepositTokenResponse>>;
+interface DepositNftEvmParams {
+    client: IDosGamesClient;
+    clients: EvmBridgeClients;
+    network: BlockchainNetworkDefinition;
+    /** ERC-1155 collection contract holding the NFT. */
+    nftContractAddress: Address;
+    /** On-chain token id of the NFT being deposited. */
+    tokenId: bigint;
+    /** Copies to transfer (1 for a unique NFT; ERC-1155 collections can hold fungible editions). */
+    amount: bigint;
+    titleID: string;
+    category?: string;
+}
+/**
+ * Full EVM NFT-deposit flow: `safeTransferFrom(account, pool, id, amount, data)` on the ERC-1155
+ * collection — where `data = abi.encode(userID, titleID, category)` — then report the tx hash so
+ * the backend verifies the transfer and grants the matching in-game item. No operator approval is
+ * needed: the player transfers their own token, so msg.sender == from.
+ */
+declare function depositNftEvm(params: DepositNftEvmParams): Promise<BridgeResult<DepositNFTResponse>>;
+interface DepositNft721EvmParams {
+    client: IDosGamesClient;
+    clients: EvmBridgeClients;
+    network: BlockchainNetworkDefinition;
+    /** ERC-721 collection contract holding the NFT. */
+    nftContractAddress: Address;
+    /** On-chain token id of the unique NFT being deposited. */
+    tokenId: bigint;
+    titleID: string;
+    category?: string;
+}
+/**
+ * Full EVM ERC-721 NFT-deposit flow: `safeTransferFrom(account, pool, tokenId, data)` on the
+ * ERC-721 collection — where `data = abi.encode(userID, titleID, category)` — then report the tx
+ * hash so the backend verifies the transfer and grants the matching in-game unique item. No
+ * operator approval is needed: the player transfers their own token, so msg.sender == from.
+ */
+declare function depositNftEvm721(params: DepositNft721EvmParams): Promise<BridgeResult<DepositNFTResponse>>;
+
+/**
+ * Submits a server-signed ERC-20 withdrawal on-chain by calling `withdrawERC20` on the RewardPool.
+ * Every field comes straight from the server's {@link WithdrawalSignatureResponse}; the client
+ * only echoes them (Amount and Nonce are decimal strings the server already scaled to raw units,
+ * and userID/titleID/category are part of the signed hash — passing anything else reverts). Use
+ * this directly to submit a fresh signature from `retryWithdrawal`.
+ */
+declare function submitEvmTokenWithdrawal(clients: EvmBridgeClients, sig: WithdrawalSignatureResponse): Promise<Hex>;
+/**
+ * Submits a server-signed ERC-1155 game-NFT withdrawal on-chain. The v2 backend signs a MINT voucher
+ * (tag "ERC1155_MINT") against the ItemBridge — `sig.ContractAddress` is the bridge and
+ * `sig.TokenAddress` is the collection — so this calls `withdrawERC1155Mint`, NOT RewardPool's
+ * `withdrawERC1155` (which would fail the selector/hash-tag check).
+ */
+declare function submitEvmNftWithdrawal(clients: EvmBridgeClients, sig: WithdrawalSignatureResponse): Promise<Hex>;
+/**
+ * Submits a server-signed ERC-721 unique game-NFT withdrawal on-chain via the ItemBridge's
+ * `withdrawERC721Mint` (MINT voucher, tag "ERC721_MINT"; `sig.ContractAddress` = bridge,
+ * `sig.TokenAddress` = collection) — not RewardPool's custody `withdrawERC721`.
+ */
+declare function submitEvmNftWithdrawal721(clients: EvmBridgeClients, sig: WithdrawalSignatureResponse): Promise<Hex>;
+interface WithdrawTokenEvmParams {
+    client: IDosGamesClient;
+    clients: EvmBridgeClients;
+    currencyID: string;
+    networkID: string;
+    /** Destination wallet — usually the connected `clients.account`. */
+    walletAddress: string;
+    /** Human decimal amount to withdraw (the server converts and signs raw units). */
+    amount: string;
+    category?: string;
+}
+/**
+ * Full EVM token-withdrawal flow: `requestTokenWithdrawal` (debits in-game immediately and returns
+ * a signed payload) → `withdrawERC20` on-chain → `confirmWithdrawal` with the resulting hash.
+ *
+ * On a failure AFTER the request succeeded, the returned {@link BridgeFailure} carries
+ * `titleTransactionID` (the asset is already debited — recover with `retryWithdrawal` while
+ * Pending, or `confirmWithdrawal` if the tx actually landed) and, when the on-chain leg landed,
+ * `onChainTxHash`. Never restart with a fresh `requestTokenWithdrawal` — that debits twice.
+ */
+declare function withdrawTokenEvm(params: WithdrawTokenEvmParams): Promise<BridgeResult<TokenWithdrawalResponse>>;
+interface WithdrawNftEvmParams {
+    client: IDosGamesClient;
+    clients: EvmBridgeClients;
+    itemID: string;
+    networkID: string;
+    walletAddress: string;
+    /** Copies to withdraw, as an integer string (usually "1"). */
+    amount: string;
+    category?: string;
+}
+/** Full EVM NFT-withdrawal flow: `requestNFTWithdrawal` → `withdrawERC1155` → `confirmWithdrawal`. */
+declare function withdrawNftEvm(params: WithdrawNftEvmParams): Promise<BridgeResult<NFTWithdrawalResponse>>;
+
+/**
+ * The on-chain half of the Solana bridge, delegated to the title's own program integration.
+ *
+ * Unlike EVM — where the RewardPool ABI is fully known and viem builds the calls — the Solana
+ * RewardPool is a custom program whose instruction/account layout (DepositSpl, withdraw_spl + the
+ * ed25519 sig-verify instruction) lives in that program's IDL, NOT in this client SDK. So the
+ * bridge asks you to provide these two calls, built with your program's IDL / `@solana/web3.js`
+ * (or Anchor) against the connected wallet from `@solana/wallet-adapter-react`. The SDK-side
+ * orchestration (request → submit → confirm, deposit → report) is identical to EVM and handled by
+ * {@link depositTokenSolana} / {@link withdrawTokenSolana}.
+ */
+interface SolanaProgramAdapter {
+    /**
+     * Builds and sends the on-chain `DepositSpl` transfer of `amountRaw` base units of `mint` into
+     * the platform program pool, embedding the identifiers the backend reads back
+     * (`GetDepositSplCallDetailsBySignature` verifies `userID`). Returns the transaction signature.
+     */
+    depositSpl(params: {
+        mint: string;
+        amountRaw: bigint;
+        userID: string;
+        titleID: string;
+        category: string;
+    }): Promise<string>;
+    /**
+     * Builds and sends the on-chain `withdraw_spl` transaction from a server-issued signature
+     * payload — including the ed25519 sig-verify instruction at `SigIxIndex` carrying
+     * `Ed25519PublicKey`/`Ed25519Message`/`SignatureHex`. Returns the transaction signature.
+     */
+    submitWithdrawal(sig: SolanaWithdrawalSignature): Promise<string>;
+}
+
+interface DepositTokenSolanaParams {
+    client: IDosGamesClient;
+    adapter: SolanaProgramAdapter;
+    network: BlockchainNetworkDefinition;
+    /** SPL mint of the token being deposited. */
+    mint: string;
+    /** Raw base-unit amount (already scaled by the mint's decimals). */
+    amountRaw: bigint;
+    titleID: string;
+    category?: string;
+}
+/**
+ * Full Solana token-deposit flow: your {@link SolanaProgramAdapter.depositSpl} sends the on-chain
+ * transfer, then `client.blockchain.depositToken` reports the signature so the backend verifies
+ * and credits the in-game balance. Mirrors {@link depositTokenEvm}.
+ */
+declare function depositTokenSolana(params: DepositTokenSolanaParams): Promise<BridgeResult<DepositTokenResponse>>;
+interface WithdrawTokenSolanaParams {
+    client: IDosGamesClient;
+    adapter: SolanaProgramAdapter;
+    currencyID: string;
+    networkID: string;
+    walletAddress: string;
+    amount: string;
+    category?: string;
+}
+/**
+ * Full Solana token-withdrawal flow: `requestTokenWithdrawal` → your
+ * {@link SolanaProgramAdapter.submitWithdrawal} sends the `withdraw_spl` tx → `confirmWithdrawal`.
+ * Same recovery semantics as EVM: a post-request failure carries `titleTransactionID` (already
+ * debited — retry, don't re-request). Mirrors {@link withdrawTokenEvm}.
+ */
+declare function withdrawTokenSolana(params: WithdrawTokenSolanaParams): Promise<BridgeResult<TokenWithdrawalResponse>>;
+
+export { writeAndWait as A, type BridgeFailure as B, type DepositNft721EvmParams as D, type EvmBridgeClients as E, type SolanaProgramAdapter as S, type WalletLoginResult as W, type BridgeResult as a, type BridgeStage as b, type BridgeSuccess as c, type DepositNftEvmParams as d, type DepositTokenEvmParams as e, type DepositTokenSolanaParams as f, type WalletLoginFailure as g, type WalletLoginStage as h, type WalletLoginSuccess as i, type WithdrawNftEvmParams as j, type WithdrawTokenEvmParams as k, type WithdrawTokenSolanaParams as l, bridgeFail as m, depositNftEvm as n, depositNftEvm721 as o, depositTokenEvm as p, depositTokenSolana as q, ensureErc20Allowance as r, submitEvmNftWithdrawal as s, submitEvmNftWithdrawal721 as t, submitEvmTokenWithdrawal as u, toErrorMessage as v, walletLoginFail as w, withdrawNftEvm as x, withdrawTokenEvm as y, withdrawTokenSolana as z };