@idosgames/wallet 0.1.6 → 0.1.8

package/dist/react/solanaIndex.d.ts

@@ -0,0 +1,99 @@
+import { SolanaAdapter } from '@reown/appkit-adapter-solana';
+import { BaseWalletAdapter } from '@solana/wallet-adapter-base';
+import { a as AppKitSolanaNetwork } from '../chains-B_P3u8_S.js';
+export { g as solanaDevnet, h as solanaMainnet } from '../chains-B_P3u8_S.js';
+import { ClientState, DepositTokenResponse, TokenWithdrawalResponse, IDosGamesClient } from '@idosgames/core';
+import { D as DepositTokenSolanaParams, W as WithdrawTokenSolanaParams, S as SolanaProgramAdapter } from '../bridge-BJnRn3NX.js';
+import { W as WalletLoginResult, a as BridgeResult } from '../types-C11zAA05.js';
+import { CSSProperties, ReactNode } from 'react';
+import 'viem';
+
+interface SolanaWalletConfigOptions {
+    /**
+     * WalletConnect Cloud / Reown project id. Required: it is what gives phones a working wallet at
+     * all. Solana's own Mobile Wallet Adapter is Android-only — on iOS a plain web page cannot reach
+     * a wallet app except through WalletConnect deep-links (or the wallet's in-app browser).
+     */
+    walletConnectProjectId: string;
+    /** Networks the title supports. Defaults to Solana mainnet. */
+    networks?: [AppKitSolanaNetwork, ...AppKitSolanaNetwork[]];
+    /** App name/metadata shown in the wallet's connect prompt. */
+    appName?: string;
+    appUrl?: string;
+    appIcon?: string;
+    /**
+     * Extra standard Solana wallet adapters (Phantom, Solflare, Mobile Wallet Adapter…).
+     *
+     * These do NOT replace the WalletConnect path — AppKit runs both: adapters cover browser
+     * extensions, wallet in-app browsers and Android's MWA, while WalletConnect covers iOS and any
+     * wallet the player has not installed as an extension. Wallet Standard already auto-detects most
+     * installed wallets, so this is only needed for ones that do not announce themselves.
+     */
+    wallets?: BaseWalletAdapter[];
+}
+/**
+ * Builds the Solana wallet stack for a title, on **Reown AppKit** — the same modal, session and
+ * deep-link machinery the EVM side uses, so both chains behave identically on a phone.
+ *
+ * A title is EVM or Solana, so exactly one of {@link createEvmWalletConfig} /
+ * `createSolanaWalletConfig` runs per game; both register the shared AppKit instance the sign-in
+ * button opens.
+ */
+declare function createSolanaWalletConfig(options: SolanaWalletConfigOptions): SolanaAdapter;
+
+type DepositTokenArgs = Omit<DepositTokenSolanaParams, "client" | "adapter" | "titleID">;
+/** `walletAddress` defaults to the connected wallet if omitted. */
+type WithdrawTokenArgs = Omit<WithdrawTokenSolanaParams, "client" | "adapter" | "walletAddress"> & {
+    walletAddress?: string;
+};
+interface SolanaBridge {
+    connected: boolean;
+    account: string | null;
+    /**
+     * Logs into the game with the connected Solana wallet by signing a server challenge (no tx, no
+     * fee). `networkID` is the cfg.Blockchain.Networks key; `walletAddress` defaults to the connected
+     * account. Requires a wallet that supports `signMessage`. Returns the fresh ClientState.
+     */
+    loginWithWallet(networkID: string, walletAddress?: string): Promise<WalletLoginResult<ClientState>>;
+    depositToken(args: DepositTokenArgs): Promise<BridgeResult<DepositTokenResponse>>;
+    withdrawToken(args: WithdrawTokenArgs): Promise<BridgeResult<TokenWithdrawalResponse>>;
+}
+/**
+ * The ergonomic Solana bridge hook: binds the connected wallet-adapter wallet + your
+ * {@link SolanaProgramAdapter} to the deposit/withdraw flows against a core client + title.
+ * The on-chain instruction building lives in the adapter (it owns the program IDL); this hook
+ * just wires the connected address and threads the request → submit → confirm lifecycle.
+ */
+declare function useSolanaBridge(client: IDosGamesClient, titleID: string, adapter: SolanaProgramAdapter): SolanaBridge;
+
+interface SolanaWalletLoginProps {
+    /** The (not yet authenticated) shared client. */
+    client: IDosGamesClient;
+    /** NetworkID the challenge is issued for — one of the title's configured networks. */
+    networkID: string;
+    /** Called once the wallet signature has been exchanged for a session. */
+    onAuthenticated: () => void;
+    disabled?: boolean;
+    label?: string;
+    style?: CSSProperties;
+    /**
+     * Fire the sign-in immediately on mount instead of waiting for a click. Used by the lazy wrapper,
+     * which already consumed the player's click to load this module — a second tap would be a bug.
+     */
+    autoStart?: boolean;
+}
+/**
+ * Ready-made "sign in with wallet" button for **Solana** titles: connect → sign the challenge →
+ * session. The EVM twin is {@link WalletLogin}; a title is one or the other.
+ *
+ * Unlike the EVM button this needs no provider wrapper — AppKit is a global instance created by
+ * `createSolanaWalletConfig`, and the wallet is read through its hooks.
+ *
+ * Connecting and signing are one action for the player, but on a phone they are separated by an app
+ * switch: `appKit.open()` returns as soon as the modal is on screen, long before a wallet is picked
+ * and the deep-link round trip completes. So the click only *arms* the flow, and an effect fires the
+ * signature once the account actually appears — no polling, no second tap.
+ */
+declare function SolanaWalletLogin(props: SolanaWalletLoginProps): ReactNode;
+
+export { AppKitSolanaNetwork, type SolanaBridge, type SolanaWalletConfigOptions, SolanaWalletLogin, type SolanaWalletLoginProps, createSolanaWalletConfig, useSolanaBridge };

package/dist/react/solanaIndex.js

@@ -0,0 +1 @@
+import {b,a as a$1,c}from'../chunk-44AGTUFV.js';import {a,b as b$2}from'../chunk-ZL42KPPC.js';import {b as b$1,c as c$1}from'../chunk-K62NMX3A.js';import {l}from'../chunk-HQNS6ZWL.js';export{m as solanaDevnet,l as solanaMainnet}from'../chunk-HQNS6ZWL.js';import {SolanaAdapter}from'@reown/appkit-adapter-solana';import {createAppKit,useAppKitAccount,useAppKitProvider}from'@reown/appkit/react';import {useState,useRef,useCallback,useEffect}from'react';import {jsxs,Fragment,jsx}from'react/jsx-runtime';function J(e){let{walletConnectProjectId:r,appName:n,appUrl:a$1,appIcon:i,wallets:t}=e,c=e.networks??[l],s=a$1??(typeof window<"u"?window.location.origin:""),o={name:n??"iDosGames",description:n??"iDosGames game",url:s,icons:i?[i]:[]},l$1=new SolanaAdapter(t?{wallets:t}:{});return a(createAppKit({adapters:[l$1],networks:c,projectId:r,metadata:o,features:{analytics:false,email:false,socials:false}})),l$1}var _="Wallet not connected.";function X(e,r,n){let{address:a}=useAppKitAccount(),{walletProvider:i}=useAppKitProvider("solana"),t=a??null,c$2=i?.signMessage?.bind(i);return {connected:!!t,account:t,loginWithWallet:(s,o)=>{let l=o??t;return l?c$2?c({client:e,networkID:s,walletAddress:l,signMessage:c$2}):Promise.resolve(c$1("sign","The connected wallet does not support message signing.")):Promise.resolve(c$1("challenge",_))},depositToken:s=>a$1({client:e,adapter:n,titleID:r,...s}),withdrawToken:s=>{let o=s.walletAddress??t;return o?b({client:e,adapter:n,...s,walletAddress:o}):Promise.resolve(b$1("request",_))}}}var $=18e4,ee=9e4;function te(e){try{let n=e?.session?.peer?.metadata?.redirect,a=n?.native||n?.universal;return !a||typeof window>"u"?!1:(window.location.href=a,!0)}catch{return  false}}function ne(e,r){return new Promise((n,a)=>{let i=setTimeout(()=>a(new Error("The wallet request timed out.")),r);e.then(t=>{clearTimeout(i),n(t);},t=>{clearTimeout(i),a(t instanceof Error?t:new Error(String(t)));});})}function oe(e){let r="Wallet sign-in failed. Please try again.";return e instanceof Error?/user (rejected|denied|cancelled|canceled)|rejected the request/i.test(e.message)?"Request declined in the wallet.":/timed? ?out/i.test(e.message)?"The wallet did not respond. Open your wallet and try again.":r:r}function re(e){let{client:r,networkID:n,onAuthenticated:a,disabled:i,label:t,style:c$1,autoStart:s}=e,{address:o,isConnected:l}=useAppKitAccount(),{walletProvider:p}=useAppKitProvider("solana"),[q,f]=useState(false),[D,d]=useState(null),[I,y]=useState(false),[K,x]=useState(false),m=useRef(null),N=useRef(0),g=useCallback(()=>{m.current&&clearTimeout(m.current),m.current=null;},[]);useEffect(()=>g,[g]);let k=useRef(false),A=useCallback(async()=>{let w=++N.current,W=()=>N.current===w,B=p?.signMessage?.bind(p);if(!o||!B){d("The connected wallet cannot sign messages."),f(false);return}f(true),d(null);try{x(!0);let u=await ne(c({client:r,networkID:n,walletAddress:o,signMessage:B}),ee);if(!W())return;if(u.ok){a();return}d(u.stage==="sign"?"Signature declined.":u.error??"Wallet sign-in failed.");}catch(u){if(!W())return;console.error("[idosgames/wallet] solana sign-in failed:",u),d(oe(u));}finally{W()&&(f(false),x(false));}},[o,p,r,n,a]),j=useCallback(()=>{te(p)||b$2()?.open();},[p]);useEffect(()=>{!I||!l||!o||!p||(y(false),g(),A());},[I,l,o,p,A,g]);let E=()=>{if(K){j();return}if(d(null),k.current=true,l&&o&&p){A();return}let w=b$2();if(!w){d("Wallet sign-in is not configured for this title.");return}f(true),y(true),g(),m.current=setTimeout(()=>{y(false),f(false),d("No wallet was connected.");},$),w.open();};return useEffect(()=>{!s||k.current||(k.current=true,E());},[s]),jsxs(Fragment,{children:[jsx("button",{type:"button",onClick:E,disabled:i,style:{...ae,...i?{opacity:.6,cursor:"default"}:null,...c$1},children:K?"Waiting for signature \u2014 tap to open wallet":q?"Check your wallet\u2026":l?t??"Sign in with wallet":"Connect wallet"}),D&&jsx("span",{role:"alert",style:ie,children:D})]})}var ae={padding:"11px 16px",borderRadius:"8px",border:"none",background:"#4c3fa8",color:"#fff",font:"inherit",fontWeight:600,cursor:"pointer"},ie={display:"block",marginTop:"6px",color:"#ff9b9b",fontSize:"13px",textAlign:"center"};export{re as SolanaWalletLogin,J as createSolanaWalletConfig,X as useSolanaBridge};

package/dist/types-C11zAA05.d.cts

@@ -0,0 +1,57 @@
+/**
+ * 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;
+
+export { type BridgeFailure as B, type WalletLoginResult as W, type BridgeResult as a, type BridgeStage as b, type BridgeSuccess as c, type WalletLoginFailure as d, type WalletLoginStage as e, type WalletLoginSuccess as f, bridgeFail as g, toErrorMessage as t, walletLoginFail as w };

package/dist/types-C11zAA05.d.ts

@@ -0,0 +1,57 @@
+/**
+ * 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;
+
+export { type BridgeFailure as B, type WalletLoginResult as W, type BridgeResult as a, type BridgeStage as b, type BridgeSuccess as c, type WalletLoginFailure as d, type WalletLoginStage as e, type WalletLoginSuccess as f, bridgeFail as g, toErrorMessage as t, walletLoginFail as w };

package/dist/withdraw-C-sFNUnQ.d.ts

@@ -0,0 +1,148 @@
+import { PublicClient, WalletClient, Address, Abi, ContractFunctionName, ContractFunctionArgs, Hex } from 'viem';
+import { IDosGamesClient, BlockchainNetworkDefinition, DepositNFTResponse, DepositTokenResponse, WithdrawalSignatureResponse, NFTWithdrawalResponse, TokenWithdrawalResponse } from '@idosgames/core';
+import { a as BridgeResult } from './types-C11zAA05.js';
+
+/**
+ * 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>>;
+
+export { type DepositNft721EvmParams as D, type EvmBridgeClients as E, type WithdrawNftEvmParams as W, type DepositNftEvmParams as a, type DepositTokenEvmParams as b, type WithdrawTokenEvmParams as c, depositNftEvm as d, depositNftEvm721 as e, depositTokenEvm as f, ensureErc20Allowance as g, submitEvmNftWithdrawal721 as h, submitEvmTokenWithdrawal as i, withdrawTokenEvm as j, writeAndWait as k, submitEvmNftWithdrawal as s, withdrawNftEvm as w };

package/dist/withdraw-CwX4HY2X.d.cts

@@ -0,0 +1,148 @@
+import { PublicClient, WalletClient, Address, Abi, ContractFunctionName, ContractFunctionArgs, Hex } from 'viem';
+import { IDosGamesClient, BlockchainNetworkDefinition, DepositNFTResponse, DepositTokenResponse, WithdrawalSignatureResponse, NFTWithdrawalResponse, TokenWithdrawalResponse } from '@idosgames/core';
+import { a as BridgeResult } from './types-C11zAA05.cjs';
+
+/**
+ * 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>>;
+
+export { type DepositNft721EvmParams as D, type EvmBridgeClients as E, type WithdrawNftEvmParams as W, type DepositNftEvmParams as a, type DepositTokenEvmParams as b, type WithdrawTokenEvmParams as c, depositNftEvm as d, depositNftEvm721 as e, depositTokenEvm as f, ensureErc20Allowance as g, submitEvmNftWithdrawal721 as h, submitEvmTokenWithdrawal as i, withdrawTokenEvm as j, writeAndWait as k, submitEvmNftWithdrawal as s, withdrawNftEvm as w };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@idosgames/wallet",
-  "version": "0.1.6",
+  "version": "0.1.8",
   "description": "Wallet-bridge companion to @idosgames/core: connect browser & mobile wallets (EVM via wagmi/viem/WalletConnect, Solana via wallet-adapter) and move tokens/NFTs in and out of the game through client.blockchain.",
   "type": "module",
   "license": "MIT",
@@ -42,6 +42,16 @@
       "types": "./dist/react/index.d.ts",
       "import": "./dist/react/index.js",
       "require": "./dist/react/index.cjs"
+    },
+    "./react/solana": {
+      "types": "./dist/react/solanaIndex.d.ts",
+      "import": "./dist/react/solanaIndex.js",
+      "require": "./dist/react/solanaIndex.cjs"
+    },
+    "./react/lazy": {
+      "types": "./dist/react/lazyIndex.d.ts",
+      "import": "./dist/react/lazyIndex.js",
+      "require": "./dist/react/lazyIndex.cjs"
     }
   },
   "files": [
@@ -57,14 +67,12 @@
   "dependencies": {
     "@idosgames/core": "^0.1.1",
     "@reown/appkit": "^1.8.23",
+    "@reown/appkit-adapter-solana": "^1.8.23",
     "@reown/appkit-adapter-wagmi": "^1.8.23",
-    "@solana/web3.js": "^1.98.4",
-    "@walletconnect/ethereum-provider": "^2.21.1",
     "viem": "^2.55.2"
   },
   "peerDependencies": {
     "@solana/wallet-adapter-base": "^0.9.27",
-    "@solana/wallet-adapter-react": "^0.15.39",
     "@tanstack/react-query": "^5.101.2",
     "react": "^18.3.1 || ^19.0.0",
     "wagmi": "^3.0.0"
@@ -81,9 +89,6 @@
     },
     "@solana/wallet-adapter-base": {
       "optional": true
-    },
-    "@solana/wallet-adapter-react": {
-      "optional": true
     }
   },
   "devDependencies": {