Adapter is PUBNET-only: testnet dapps using the Wallets Kit default modules connect, then fail on first signature

Start with dist/types.mjs and dist/adapter.mjs, then inspect the corresponding source files and tests for Scope, requestAccess(), disconnect(), and selectScopeWithPriority(). Check whether the MetaMask multichain API supports the proposed testnet and futurenet scopes before implementing the change. Done means supported scopes can be selected and revoked correctly while existing callers still default to pubnet, with tests covering network details and signing.

Summary

MetaMaskStellarAdapter only ever knows about stellar:pubnet, so dapps running on testnet or futurenet cannot use it. Because MetaMaskModule is now in the Stellar Wallets Kit's defaultModules() and sep43Modules() (kit 2.7.0+), those dapps don't just miss out — MetaMask appears in the wallet picker, connects, and then fails at the first signing call.

Would you accept a PR adding testnet (and futurenet) scopes?

Why this affects more than one dapp

In @creit.tech/[email protected], esm/sdk/modules/utils.js:

export function defaultModules(opts) {
  const modules = [ ..., new MetaMaskModule(), new GhostsigModule() ];
  ...
}
export function sep43Modules(opts) {
  const modules = [ new FreighterModule(), new DcentModule(), new MetaMaskModule(), new GhostsigModule() ];
  ...
}

Any kit dapp that takes the defaults and runs on testnet — which is most of them during development — now offers MetaMask and breaks on it. The dapp author hasn't opted into anything.

What happens today

On a testnet dapp, in order:

1. isAvailable() → true for every visitor with MetaMask installed, so it shows up in the picker.
2. requestAccess() → createSession(Scope.PUBNET), i.e. it opens a mainnet session regardless of the dapp's network.
3. getNetwork() → { network: 'PUBLIC', networkPassphrase: 'Public Global Stellar Network ; September 2015' }.
4. signTransaction / signMessage / signAuthEntry with the dapp's testnet passphrase → networkPassphraseToScope() throws Unknown network passphrase: Test SDF Network ; September 2015, surfacing as UNSUPPORTED_NETWORK (-4).

A dapp that checks getNetwork() at connect time can at least block it, but only after the user has picked MetaMask. A dapp that doesn't check gets the failure at step 4, which reads as the wallet being broken.

Where it's pinned (0.3.0)

dist/types.mjs:

export var Scope;
(function (Scope) {
    Scope["PUBNET"] = "stellar:pubnet";
})(Scope || (Scope = {}));

export const NETWORK_PASSPHRASE = {
    [Scope.PUBNET]: 'Public Global Stellar Network ; September 2015',
};
export const NETWORK_NAME = {
    [Scope.PUBNET]: 'PUBLIC',
};

Plus the two hardcoded call sites in dist/adapter.mjs — createSession(Scope.PUBNET) in requestAccess(), and revokeSession({ scopes: [Scope.PUBNET] }) in disconnect() — and selectScopeWithPriority(), whose name suggests multiple scopes were the intent:

selectScopeWithPriority(session) {
    const available = new Set(Object.keys(session?.sessionScopes ?? {}));
    return available.has(Scope.PUBNET) ? Scope.PUBNET : undefined;
}

There's also a NOTE in types.mjs that reads like this was known to be unfinished:

NOTE: Confirm these scope values with the MetaMask Stellar snap team before finalizing.

What we'd need

Per CAIP-2 for Stellar, adding stellar:testnet (and stellar:futurenet) to Scope, NETWORK_PASSPHRASE and NETWORK_NAME, then letting the scope be chosen rather than fixed:

• requestAccess() taking the desired scope (defaulting to PUBNET, so no behaviour change for current callers)
• disconnect() revoking whichever scopes the session actually holds
• selectScopeWithPriority() honouring its name

Happy to open the PR if the shape is agreeable — the main thing we can't determine from outside is whether the MetaMask multichain API will grant a stellar:testnet scope today, or whether the wallet side needs to land first. If it's the latter, that's useful to know too, and we'll track it.

Our use case, for context

We're ProofBridge, a P2P cross-chain settlement protocol bridging EVM and Stellar. We're on testnet through our current build phase, so this adapter is unusable for us right now — despite being, on capability, the best Stellar wallet integration available to us: it's the only module in the kit implementing signAuthEntry, and its signMessage is proper SEP-53, which several kit modules either stub out or implement non-standardly.

MetaMask holding native Stellar accounts is genuinely significant for a protocol like ours, because it collapses a two-wallet onboarding step (an EVM wallet and a Stellar wallet) into one. We'd like to ship it. Testnet is the only thing in the way.