feat(universal-provider): add explicit solaxy namespace support #7116
Conversation
Add solaxy as an explicitly supported namespace in UniversalProvider, using the GenericProvider for RPC communication. This enables WalletConnect support for the Solaxy (SVM) ecosystem via CAIP-2 chain ID solaxy:1936682104. Includes test coverage for solaxy namespace initialization.
There was a problem hiding this comment.
Pull request overview
This PR adds explicit support for the Solaxy namespace to the UniversalProvider by adding a case statement in the provider creation switch and including test coverage.
Changes:
- Adds
case "solaxy":in thecreateProviders()switch statement to explicitly handle Solaxy namespace - Adds unit test validating that solaxy namespace initializes with GenericProvider
- Enables WalletConnect integration for Solaxy ecosystem using CAIP-2 chain ID
solaxy:1936682104
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| providers/universal-provider/src/UniversalProvider.ts | Adds explicit solaxy case in switch statement (falls through to default GenericProvider) |
| providers/universal-provider/test/index.spec.ts | Adds test case validating solaxy namespace provider initialization |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| it("should init generic provider for solaxy namespace", async () => { | ||
| // #given | ||
| const dapp = await UniversalProvider.init({ | ||
| ...TEST_PROVIDER_OPTS, | ||
| name: "dapp", | ||
| }); | ||
| const wallet = await UniversalProvider.init({ | ||
| ...TEST_PROVIDER_OPTS, | ||
| name: "wallet", | ||
| }); | ||
| const solaxyChains = ["solaxy:1936682104"]; | ||
| const solaxyAddress = "SoLaXyAddressExample123456789"; | ||
|
|
||
| // #when | ||
| await testConnectMethod( | ||
| { | ||
| dapp, | ||
| wallet, | ||
| }, | ||
| { | ||
| requiredNamespaces: {}, | ||
| optionalNamespaces: {}, | ||
| namespaces: { | ||
| solaxy: { | ||
| accounts: solaxyChains.map((chain) => `${chain}:${solaxyAddress}`), | ||
| chains: solaxyChains, | ||
| methods: ["getBlockHeight", "getBalance"], | ||
| events: ["chainChanged"], | ||
| }, | ||
| }, | ||
| }, | ||
| ); | ||
| await throttle(1_000); | ||
|
|
||
| // #then | ||
| expect(dapp.rpcProviders).to.be.an("object"); | ||
| expect(dapp.rpcProviders.solaxy).to.exist; | ||
| expect(dapp.rpcProviders.solaxy).to.be.an("object"); | ||
|
|
||
| const solaxyHttpProviders = dapp.rpcProviders.solaxy.httpProviders; | ||
| expect(Object.keys(solaxyHttpProviders).length).to.eql(solaxyChains.length); | ||
|
|
||
| Object.values(solaxyHttpProviders).forEach((provider, i) => { | ||
| const url = provider.connection.url as string; | ||
| expect(url).to.include("https://"); | ||
| expect(url).to.include(RPC_URL); | ||
| expect(url).to.eql( | ||
| getRpcUrl(solaxyChains[i], {} as Namespace, TEST_PROVIDER_OPTS.projectId), | ||
| ); | ||
| }); | ||
|
|
||
| await deleteProviders({ A: dapp, B: wallet }); | ||
| }); |
There was a problem hiding this comment.
This test is functionally identical to the existing test "should init generic provider if provider for given namespace doesn't exist" (lines 1564-1631), which already validates that any namespace without a specific provider falls back to GenericProvider.
The test adds value as documentation showing that solaxy is supported, but consider whether this level of duplication is necessary. If the explicit case "solaxy": is removed from the switch statement (as it provides no unique behavior), this test becomes redundant since solaxy would behave identically to other namespaces like tron and zora that are already tested.
Alternatively, if you want to keep this test for documentation purposes, consider adding a comment explaining that this test serves as documentation for solaxy support rather than testing unique behavior.
| namespace: combinedNamespace, | ||
| }); | ||
| break; | ||
| case "solaxy": |
There was a problem hiding this comment.
The explicit case "solaxy": statement before the default: case creates a fall-through pattern that is redundant and potentially confusing. Since there's no break statement and no code in the solaxy case, it behaves identically to any other namespace hitting the default case.
This means the solaxy namespace will already be handled by the default case without needing an explicit case statement. The explicit case adds no functionality and may mislead future maintainers into thinking solaxy requires special handling when it doesn't.
Consider either:
- Removing the explicit
case "solaxy":line entirely, as the default case already handles it correctly - Adding a comment explaining that solaxy intentionally uses GenericProvider (e.g.,
// solaxy uses GenericProvider (falls through to default))
| case "solaxy": |
|
Quick clarification on my side — the previously mentioned solaxy:1936682104 was my mistake. For Solaxy mainnet, the correct CAIP-2 chain ID (Solana cluster genesis) is: solana:5oapfnaq6jkzYPhnrB9Rnaaff4bG2UskksEY6PvPhQan Thanks again for the clean implementation using GenericProvider 👍 |
Summary
solaxycase inUniversalProvider.createProviders()switch statementGenericProviderfor Solaxy RPC communication (Solana VM compatible)solaxy:1936682104Context
This is a clean reimplementation of the feature requested in #7016, which had several issues:
solana.tsprovider file that was referenced but not includedThis PR takes a simpler approach by using the existing
GenericProvider, which is sufficient for Solaxy's Solana-compatible RPC methods.Test plan
should init generic provider for solaxy namespacenpm run testinproviders/universal-providerNote
Adds explicit support for the
solaxynamespace in UniversalProvider and verifies it with unit tests.solaxycase inUniversalProvider.createProviders()to instantiateGenericProvidersolaxy:1936682104with HTTP provider URL resolution validatedshould init generic provider for solaxy namespaceensuring provider creation and RPC URL generation@walletconnect/universal-providerWritten by Cursor Bugbot for commit fb52ee2. This will update automatically on new commits. Configure here.