fix: derive capabilities from session namespaces when chainIds is omitted

[bakoushin]

Description

Updates wallet_getCapabilities handling to fall back on the session’s namespace chain IDs when no explicit chainIds are provided in the request.

Per EIP-5792, the chainIds parameter is optional. If it is omitted, the wallet is expected to return capabilities for all supported chains.

With this fix, the wallet correctly enumerates capabilities across all chains defined in the session namespaces, ensuring compliance with the spec and avoiding incomplete responses when chainIds is absent.

Type of change

• Chore (non-breaking change that addresses non-functional tasks, maintenance, or code quality improvements)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Draft PR (breaking/non-breaking change which needs more work for having a proper functionality [Mark this PR as ready to review only when completely ready])
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How has this been tested?

• Updated unit test

Examples

1. Wallet provided scopedProperties as a part of session approval:

...
namespaces: {
  eip155: {
    chains: ["eip155:1", "eip155:137", "eip155:84532"],
  },
},
scopedProperties: {
  "eip155:1": {
    atomic: {
      status: "unsupported",
    },
  },
  "eip155:137": {
    "eip155:137:0x0910e12C68d02B561a34569E1367c9AAb42bd811": {
      atomic: {
        status: "supported",
      },
    },
  },
  "eip155:84532": {
    "eip155:84532:0x0910e12C68d02B561a34569E1367c9AAb42bd810": {
      atomic: {
        status: "supported",
      },
    },
  },
},
...

2. dApp is requesting wallet_getCapabilities without providing an optional array of chain ids:

wallet_getCapabilities([
  "0x0910e12C68d02B561a34569E1367c9AAb42bd811", // wallet address
                                                // no explicitly provided chain ids as they are optional
])

3. Method execution:

Before	After
Capabilities are NOT extracted from session, since no chainIds are provided	Capabilities are extracted for all chain ids supported within the session

Checklist

• I have performed a self-review of my own code
• My changes generate no new warnings
• (N/A) Any dependent changes have been merged and published in downstream modules

---

Note

extractCapabilitiesFromSession now falls back to EIP-155 session namespace chains when chainIds is not provided, with a new test covering this behavior.

• Utils:
  • Update extractCapabilitiesFromSession in providers/universal-provider/src/utils/caip25.ts to:
    • Read namespaces.eip155.chains and convert to hex chain IDs.
    • Use these as defaults when input chainIds is empty.
• Tests:
  • Add unit test (Case 9) in providers/universal-provider/test/utils.spec.ts validating fallback to session namespace chains.

^{Written by Cursor Bugbot for commit 573f2fa. This will update automatically on new commits. Configure here.}

[github-actions]

All contributors have signed the CTA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[bakoushin]

I have read the CTA Document and I hereby sign the CTA

[ganchoradkov]

thanks for the fix @bakoushin! I think the correct fix is a bit more involved though - I've added suggestions to improve it - for example to get the chains from the approved accounts rather than the chains since they are optionally present in the session. Further more I'm wondering about the case where both address specific and chain specific capabilities exist e.g.

 "eip155:137": {
          "eip155:137:0x0910e12C68d02B561a34569E1367c9AAb42bd811": {
            atomic: {
              status: "supported",
            },
          },
         paymasterService: {
              supported: true,
         },
     },

and the result should be

 "0x89": {
        atomic: {
          status: "supported",
        },
       // this capability applies to all addresses on that chain
        paymasterService: {
          supported: true,
        },
      },

this case fails because we need to loop here to get all provider capabilities
https://github.com/WalletConnect/walletconnect-monorepo/pull/6955/files#diff-c0f6b48d5568497e5d855c04009289856302dc5a75aeebb143adb37986e12c59L65-L68

[ganchoradkov]

Suggested change

	const namespaceChainIds =
	namespaces[EIP155_PREFIX]?.chains
	?.map((chain) => decimalToHex(chain.split(":")[1]))
	.filter(Boolean) ?? [];
	const namespaceChainIds =
	namespaces[EIP155_PREFIX]?.accounts
	.filter((account) => account.includes(`:${address}`))
	?.map((account) => decimalToHex(parseChainId(account).reference))
	.filter(Boolean) ?? [];

Check the accounts because we don't want to get all chains, just the chains this address was approved with

tip: you can import parseChainId from "@walletconnect/utils"

[ganchoradkov]

Suggested change

	"0x1": {
	atomic: {
	status: "unsupported",
	},
	},

with the change to loop through the accounts instead of chains, this 0x1 capabilty no longer applies

[ganchoradkov]

Suggested change

	chains: ["eip155:1", "eip155:137", "eip155:84532"],
	accounts: [
	"eip155:137:0x0910e12C68d02B561a34569E1367c9AAb42bd811",
	"eip155:84532:0x0910e12C68d02B561a34569E1367c9AAb42bd810",
	],

[bakoushin]

@ganchoradkov Thanks for the detailed feedback!

I guess it is now addressed:

• namespace chainIds are extracted with respect to approved addresses
• the resulting capabilities object is constructed by layering from the least to the most specific definitions:

1. global capabilities
2. chain-specific capabilities (if present)
3. address-specific capabilities (if present)