Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] There should be a way to disconnect wallets (eg. Bitcoin) by namespace #3977

Open
dimisus opened this issue Mar 10, 2025 · 6 comments

Comments

@dimisus
Copy link

dimisus commented Mar 10, 2025

What problem does this new feature solve?

As of know using eg. the Bitcoin adapter everything works in order to connect a wallet by namespace. But it is not possible to disconnect single wallets by namespace.

Problem: It is only possible to terminate the whole reown session on disconnect (which is to say to disconnect ALL connected wallets at once).

Describe the solution you'd like

// types should be
export declare function useDisconnect(): {
    disconnect: (namespace?:ChainNamespace) => Promise<void>;
};

// usage
import { useDisconnect } from '@reown/appkit/react';

const Comp = ({props}) => {
  const btcNamespace = 'bip122';
  const disconnect = useDisconnect();
  return <button onClick={() => disconnect(btcNamespace)}>disconnect bitcoin wallet</button>
}
@arein
Copy link
Contributor

arein commented Mar 12, 2025

@dimisus makes sense! May I ask what you're building?

@dimisus
Copy link
Author

dimisus commented Mar 12, 2025

We are currently launching a DEX. It is chain agnostic, or multichain if you wish. Currently we need a wallet solution for BTC, EVM, Tron, LTC, BCH, MultiversX. I was playing around with your new BTC adapter. It is excellent, but some features are missing. Thank you for the lib though.

@arein
Copy link
Contributor

arein commented Mar 12, 2025

@dimisus many thanks. Other than the above mentioned one, what other features are missing?

@dimisus
Copy link
Author

dimisus commented Mar 13, 2025

@arein Thanks for looking into it. Approximately what I can recollect:

  1. Within a session it would be beneficial to select the session's active namespace. So that for example interactions with functions/hooks like useWalletInfo, which is also not dependent on a namespace, would return the current active session's namespace wallet information.

  2. I desperately tried to get the currently connected wallet's metadata in a stable manner. For example I wanted to render the connected wallet's icon (let's say MetaMask). After reloading the session/page the useWalletInfo hook did not return the same information, although MM's extension was reconnected to my application. Switching to XVerse (BTC) would as well never return the same data structure as other wallets. Therefore useWalletInfo is kind of a blackbox.

    1. It was nearly impossible to have both EVM and BTC wallets connected AND access any metadata of one of the connected wallets without writing a lot of lines of hacky abstractions. useWalletInfo in such a case would never return one of the wallet's data as there is no possibility of changing the current active namespace.
  3. Events subscriptions (involving namespaces) like BTC wallet connected or EVM wallet connected.

@arein
Copy link
Contributor

arein commented Mar 13, 2025

Within a session it would be beneficial to select the session's active namespace. So that for example interactions with functions/hooks like useWalletInfo, which is also not dependent on a namespace, would return the current active session's namespace wallet information.

We shipped this today useAppKitAccount({ chainNamespace: 'bip122' })

It was nearly impossible to have both EVM and BTC wallets connected AND access any metadata of one of the connected wallets without writing a lot of lines of hacky abstractions. useWalletInfo in such a case would never return one of the wallet's data as there is no possibility of changing the current active namespace.

Hope this is better as well after today's multichain released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants