[Discussion] Unified Wallet Signing Logic for Substrate and EVM-based Networks

[CocDap]

Context:

Wallet applications need to support a variety of blockchain networks. From a signing perspective, these networks generally fall into two categories:

• Substrate-based chains (e.g., Polkadot, Kusama), which primarily use sr25519/ed25519 for signing extrinsics.
• EVM-based chains (e.g., Ethereum, Polygon), which use secp256k1 for signing transactions.
• A third, more complex category is hybrid chains (e.g., Moonbeam, Astar, Polkadot Asset Hub) that support both Substrate extrinsics and EVM transactions.

Problem Statement:

When a dApp sends a transaction request to a wallet, the wallet needs a reliable mechanism to determine which signing algorithm to use. While this is straightforward for pure Substrate or EVM chains, it becomes ambiguous for hybrid chains.

Goal:
To define a clear standard or best practice for how wallets should handle signing requests across the Polkadot and EVM ecosystems to ensure a consistent and predictable developer and user experience.

[CocDap]

Current Implementation:

• Our application's wallet connection logic is currently siloed based on the selected source network:
• When a user selects a Substrate-based chain as the From network, they are prompted to connect using LunoKit.
• When a user selects an EVM-based chain as the From network, they are prompted to connect using RainbowKit.

Problem:
This approach creates significant UX friction. Users are forced to manually manage and switch between two separate connection flows, potentially using two different wallet extensions. This is not intuitive and creates a disjointed experience, especially for users wanting to interact with both ecosystems.

Desired Outcome:
We need to implement a unified wallet connection experience where the user can connect once and seamlessly interact with both Substrate and EVM chains.

[wbh1328551759]

Hello! Thank you for raising this important issue. I understand that a unified user experience is crucial for cross-chain applications, but this problem actually falls outside the scope of LunoKit's responsibilities as a wallet connector.

Currently, most blockchain wallets are designed for specific ecosystems. Even wallets that support multiple ecosystems handle different chain types separately internally. LunoKit and RainbowKit, as connectors, can only connect to the existing functionality of these wallets.

We can consider the following improvement directions:

1. Unify the connection experience at the UI level by providing a single entry point
2. Provide better documentation and examples on how to integrate both connectors in applications

However, it's important to clarify that under current technical conditions, users will still need to authorize two different wallet extensions, and this cannot be completely resolved through connector-level improvements. The real solution requires wallet developers to provide unified APIs for handling different types of chains.