@idosgames/wallet 0.1.6 → 0.1.7

package/dist/withdraw-DTHssYc9.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 { b as BridgeResult } from './chains-DMjdV7VV.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-DgTjKpSf.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 { b as BridgeResult } from './chains-DMjdV7VV.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.7",
   "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,11 @@
       "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"
     }
   },
   "files": [
@@ -57,14 +62,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 +84,6 @@
     },
     "@solana/wallet-adapter-base": {
       "optional": true
-    },
-    "@solana/wallet-adapter-react": {
-      "optional": true
     }
   },
   "devDependencies": {

package/dist/bridge-DvafuXl9.d.cts

@@ -1,304 +0,0 @@
-import { Chain, 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;
-
-declare const mainnet: Chain;
-declare const bsc: Chain;
-declare const polygon: Chain;
-declare const base: Chain;
-declare const arbitrum: Chain;
-declare const optimism: Chain;
-declare const sepolia: Chain;
-declare const polygonAmoy: Chain;
-/** Every chain declared here, keyed by NetworkID-style name — handy for a title-driven picker. */
-declare const idosChains: {
-    readonly mainnet: Chain;
-    readonly bsc: Chain;
-    readonly polygon: Chain;
-    readonly base: Chain;
-    readonly arbitrum: Chain;
-    readonly optimism: Chain;
-    readonly sepolia: Chain;
-    readonly polygonAmoy: Chain;
-};
-/** Look up a declared chain by its EVM chain id (e.g. from the title's blockchain config). */
-declare function chainById(id: number): Chain | undefined;
-/**
- * A chain in the CAIP shape Reown AppKit expects.
- *
- * AppKit ships its own network list at `@reown/appkit/networks`, but that module is
- * `export * from "viem/chains"` — the very barrel this file exists to avoid. Converting our own
- * chains keeps AppKit working without dragging `tempo`/`ox` (and its BigInt `**`) into the bundle.
- */
-type AppKitEvmNetwork = Chain & {
-    chainNamespace: "eip155";
-    caipNetworkId: `eip155:${number}`;
-};
-/** Wraps a chain in the CAIP fields AppKit needs. */
-declare function toAppKitNetwork(chain: Chain): AppKitEvmNetwork;
-
-/**
- * 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 { type AppKitEvmNetwork as A, type BridgeFailure as B, polygonAmoy as C, type DepositNft721EvmParams as D, type EvmBridgeClients as E, sepolia as F, submitEvmNftWithdrawal as G, submitEvmNftWithdrawal721 as H, submitEvmTokenWithdrawal as I, toAppKitNetwork as J, toErrorMessage as K, walletLoginFail as L, withdrawNftEvm as M, withdrawTokenEvm as N, withdrawTokenSolana as O, writeAndWait as P, 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, arbitrum as m, base as n, bridgeFail as o, bsc as p, chainById as q, depositNftEvm as r, depositNftEvm721 as s, depositTokenEvm as t, depositTokenSolana as u, ensureErc20Allowance as v, idosChains as w, mainnet as x, optimism as y, polygon as z };