Miden wallet connectors - initial assessment

# Problem
Wallets are the primary interface through which users interact with blockchains, and this will also be true for Miden. While the Demox wallet serves as an initial implementation, it's unlikely that most users will adopt a new wallet just to access Miden. Instead, Miden’s adoption and early traction will depend on its compatibility with wallets users already trust and use. However, Miden introduces a unique model of client-side execution and local state storage, which existing wallets are not designed to support. To ensure accessibility and adoption, we need a strategy that enables users to interact with Miden through their preferred wallets—even if those wallets do not natively support Miden’s architecture.

There are two different categories of wallets, hot and cold. Most used hot wallets are MetaMask, Phantom, Coinbase wallet, Trust wallet. Most used cold wallets are Ledger and Trezor. (Its a bit hard to find real usage data, but we can go with this list for now)

For now, let's only analyse the hot wallet problem.

# Solution space
We need to evaluate different strategies for enabling wallet support within Miden’s unique architecture. Some wallet providers allow for custom integrations—for example, MetaMask offers Snaps to extend its functionality—while others, like Coinbase Wallet, are fully closed-source and more limited in terms of extensibility.

In the short term, we can take a pragmatic approach: assume that Miden’s native wallet will support the full feature set, while external wallets—connected via adapters—may be limited to interacting with public (on-chain) accounts and relying on delegated proving. This baseline can be tightened or expanded over time as needed.

At a high level, there appear to be three general approaches to integration:

## Custodial Middleware Solutions
One approach is to build a service layer that acts as a bridge between the APIs expected by mainstream wallets (e.g. Ethereum-style JSON-RPC) and the APIs provided by Miden. For instance, this would allow users to access Miden applications using wallets like Phantom, with requests being translated server-side into Miden-specific formats. This solution prioritizes compatibility and ease of use, but introduces additional trust assumptions—particularly around custody, data privacy, and transaction integrity—which would need to be carefully assessed.

## Wallet Connectors (Non-Custodial Adapters)
Another option is to build wallet connectors similar to what the Fuel network has explored ([Fuel Connectors](https://github.com/FuelLabs/fuel-connectors/wiki)). These connectors are non-custodial and designed to work with existing wallets by injecting compatibility layers or adapting signing flows. While promising, we still need to evaluate their applicability to Miden:

- How difficult would it be to implement and maintain?
- How seamless is the experience for end-users?
- How robust and reliable are these connectors in practice?

## In-Wallet Extensions ("Environment Integrations")
Some wallets offer dedicated extension environments—MetaMask Snaps being a notable example. These allow for low-level customization and could, in theory, support Miden's client-side logic. We need to investigate:
- Can a Snap be built for Miden that meets performance and UX expectations?
- Would the proving time and resource requirements be acceptable in this context?
- Do other popular wallets provide similar extension mechanisms we could leverage?

# Next steps
- [ ] Analyse if there are more solution categories. How do other chains (Aptos, Sui, Solana, ...) solve this?
- [ ] Analyse pros and cons of the different solutions, especially in terms of UX. Ideally, users could simply use Phantom (as an example) as on Solana and the rest is abstracted away
- [ ] ...