While we already have a diverse field of mobile wallets in the ecosystem, they all attempt to be complete solutions, and we have a distinct lack of mobile equivalents to our browser extensions.

Where we have solutions like Subsocial and Kodadot with mobile-ready UIs, users cannot use these applications with the same amount of security on mobile as they can on desktop, due to lack of an injected signer being available on mobile.

In the longer term, the best-in-class mobile and desktop experiences come from toolkits like Web3Modal which allow developers to build experiences agnostic of the underlying signing solution used by a given user. While Polkadot Signing solutions are significantly lighter than Ethereum's - the signer doesn't require any connection to a node endpoint, the precedent is that the application provides that - it would still be interesting to explore the feasibility of remote signing solutions (portis), relayed signatures (walletconnect), and if the existing tools in the space may be reused, or if new tooling can be created within the scope of this bounty.

One direction that is in research within the ecosystem that could lead to novel work deployed to Kusama and Polkadot is the concept of a page that stores encrypted keys in localstorage, with dapp developers loading it in an iframe and communicating with it for signatures - the idea being that the page that is loaded is specified by the user, based on their security model, up to and including a page that is hosted on localhost with a self-signed certificate as the most secure option, and a hosted wallet providing traditional username signup as the least secure option.

REQUEST FOR CURATOR:

The Curator for this proposal should be someone at least familiar with the equivalent ecosystem components in the Ethereum ecosystem - Mobile Wallets, (ie, Metamask mobile, Trust, etc) Walletconnect, Portis, and in general the Web3Modal ecosystem. And either the ability to independently verify the safety/veracity of proposals and teams applying for this bounty, or connections to individuals that can do so (who's verification work is to be funded by subbounty, presumably).

It will be the Curator's primary responsibility to deliver a mobile-first signing solution, preferably an open standard, for Polkadot, preferably without requiring users to install an additional application on their devices so that it is platform agnostic, "as secure as possible".

It should be clear that a Curator cannot directly be involved in the development of, or directly connected to the groups or individuals making proposals for, this bounty - although in this case knowledge of the ecosystem and relationships with the teams should probably be considered a positive factor in curators selection, so there will likely be a grey area between the two criteria.

REQUEST FOR PROPOSALS:

I'd be excited to see the aforementioned teams and projects extending their tools to Polkadot, but ideally any team that is capable of providing a solution that satisfies the curator selected for this bounty should apply.

It is ultimately up to the curator to determine, but I would suggest using part of this bounty to fund several PoC sub-bounties that allow self-hosted solutions for app devs and users, and use the remainder to audit and polish the most promising solution(s) - Bounties can be extended via making treasury proposals to their address, and I will support increasing this bounty's funding after the first stage of PoCs

 Approve a bounty proposal. At a later time, the bounty will be funded and become active
 and the original deposit will be returned.

 May only be called from `T::ApproveOrigin`.

 # <weight>
 - O(1).
 # </weight>

- There is a need for mobile wallets for Polkadot.
- Current mobile wallets lack security compared to desktop versions.
- Research is being done on a new mobile signing solution.
- A curator is needed to find a mobile-first signing solution for Polkadot.
- Proposals are requested from teams capable of providing a solution.

#272 Bounty Proposal: Mobile Signers / Injectors / Walletconnect equivalent