Allow Custom Wallet/Public Client Injection

[inaridiy]

Thank you for creating this SDK! It's been really helpful for integrating with INTMAX2.
However I noticed that the SDK currently hardcodes window.ethereum and the Sepolia chain in src/browser/index.ts:

this.#walletClient = createWalletClient({
  chain: sepolia,
  transport: custom(window.ethereum!),
});

this.#publicClient = createPublicClient({
  chain: sepolia,
  transport: http(),
});

While this works great for standard MetaMask users, it becomes a blocker when:

• Using modern wallet abstraction frameworks like Wagmi
• Integrating with WalletConnect or other wallet providers
• Testing on different chains or local networks
• Building apps that need to support multiple wallet types

This is particularly challenging for production apps that need to support a wide range of users with different wallet preferences.

Possible Solution

What if we could optionally inject our own client instances? Something like:

// Just a rough concept
interface ClientConfig {
  walletClient: WalletClient;
  publicClient: PublicClient;
}

interface ConstructorParams {
  // ... existing params
  clientConfig: ClientConfig; // Optional to keep backward compatibility
}

// Usage example
const client = IntMaxClient.init({
  environment: 'testnet',
  clientConfig: {
    walletClient: myCustomWalletClient,
    publicClient: myCustomPublicClient,
  }
});

This is just one possible approach - you probably have better ideas! The key thing would be maintaining backward compatibility so existing integrations don't break.
Would love to hear your thoughts on this. Happy to help with implementation if you think this direction makes sense!

[signature18632]

Thanks a lot for the suggestion — totally agree with your points!

Hardcoding window.ethereum and Sepolia was fine for initial use, but it does limit flexibility for more advanced setups like WalletConnect, Wagmi, or custom networks.

Your idea of allowing optional injection of walletClient and publicClient makes a lot of sense. We'll look into supporting this while keeping backward compatibility.

Really appreciate you bringing this up! Happy to review a PR if you're up for it — or we can take it from here and keep you posted.