Polkadot Signing - 3 Usability Problems & Solutions - Seeking Feedback

Onboarding onto Polkadot is hard and there are several areas of friction that users run into. This article identifies three of them and explains the solution I recommend.

I did not develop each of these protocols, but we have built many dapps with them on other blockchains with technical and user success. I seek feedback on the technical architecture to ensure there are no foundational flaws, any reasons why it wouldn’t work with Polkadot, and advice and support on implementation.

The Native Token Problem


Like Ethereum, you need the L1 token to do anything on Polkadot. However, in general, users don’t begin their journey with the idea of having DOT and trying to find something to do with it. They start with a problem or application (dapp) and have a desire to use it, and then realize there is another step of having to buy DOT, which creates another separate thread of painful friction.


The Network’s solution is to create Sybil-attack resistant methods for a faucet, such as verify SMS. SMS verification allows for a free initial faucet amount. It privately keeps a list of number hashes to avoid mis-use and also shields against VoIP SMS. Other methods could be verifying through a social network site such as Twitter or Github, which typically have their own Sybil protection.

Whitelisted oracles/origins that are allowed to use the initial faucet are voted in via chain governance, and those origins are allowed to use the extrinsic for new account creation and initial faucet. These oracles/origins, such as wallets or applications, will need to provide evidence to voters that they have Sybil protection in place.

Allowance for these users will be allocated at genesis and balanced via governance.

The Install-something Problem


A larger-than-you-think number of users reach the point of wanting to use web3 and then turn away when they are asked to install a new app on mobile or a browser extension. That is too much friction for a large segment of users, the so-called web3 curious or experimenters.


Don’t require the user to install anything. Hashed Network supports “Login with Google”, which uses the Google Drive API to save the user’s key, access it, and sign and broadcast directly in the browser.

Is it great security? No, because Google has access to the key. It is a compromise. As the user gets hooked, there are easy migration paths to improved self-custody with an installed signer.

Signing Ergonomics Problem - Part 1


The desktop-to-mobile signing experience lacks continuity. Parity Signer is a fantastic air-gapped wallet, but offline wallets are not practical for day-to-day usability. Some of the other wallets require that users go into the application browser, select from a list of applications or enter an address.


The more natural flow for users is to access an application via a link that opens in their default web browser. As the user navigates to Login and sign transactions, they are prompted to do so.

Signing Ergonomics Problem - Part 2


The related continuity problem is using the same account on both desktop and mobile requires moving the key.


Keep the key on the device only. When the mobile browser needs a signature, it sends a deep link (similar to a mailto: link) to the operating system to open a signer app. The transaction signature request is sent to the signer where the user approves and the application broadcasts it.

When a user access an application on desktop, they are prompted to login by scanning a QR code. The user opens their device and scans the QR code using the default camera app. The user taps the QR code, scans a login payload, and broadcasts the signature back to the browser over the network (not via webcam like Parity Signer).

This step connects the browser and device for the duration of a configurable session, which can be managed on the device. When the user performs an action in the application that requires a transaction signature, it is sent to the device over the network as a push notification. The payload is signed, signature is passed back to the application, where it is broadcast.

This feature requires a small intermediate relay, which we are investigating building directly into the Substrate node.

Action Plan

Part 1 above is made possible by a signing request protocol that can be encoded in the application and decoded by the signer.
- Should we add support for Substrate transactions?

Part 2 above is made possible by a signature provider protocol that is an open standard with support end-to-end encryption, persistent account sessions, and identity proofs.
- Should we add support for Substrate transactions?


The Native Token Problem

I think the problem is even worse in the Polkadot ecosystem and can be broken down into two sub-problems:

  1. User wants to use a dapp but does not have DOT: Problem here is that there are no dapps on Polkadot really. They are on Moonbeam, Acala, Interlay, Astar, (insert your favorite parachain). These parachains all have their own native tokens, so you need easy onboarding to the native parachain fee token, not DOT. Talisman and a couple of other wallets have a fiat onboarding that can work. But your suggested SMS verification with a faucet might also be a valid approach. I’m personally also a fan of giving tokens to target groups based on e.g., DeFi users on Ethereum like how Evmos did it.
  2. Users wants to use a dapp and already has DOT. I think in that case, parachains should likely have a way to “bring your own fees”, something like: Transaction Fees - Acala Wiki

The Install-something Problem
Do you have some numbers on that? Would be cool to learn more.

Do you have a link to that “Login with Google”? A quick search did not really yield any resources.


Thanks for the response.

Ah, yes, that is more clear re: the L1 token. I guess I consider the identity pallet on polkadot-js a dapp. Setting up a profile was my first ‘getting-started’ step. But yes, there isn’t really anything else besides that and I doubt that is a common onboard ramp.

I agree that there should tokens budgeted for groups, influencers, incentives, etc. We have that allocated to ‘ecosystem’ in the genesis allocation. The faucet would be much more tactical, just balanced against demand so long as good Sybil protection is in place, as approved via governance.

This video provides an explainer and demo of our “Login with Google” feature, at about the 7m mark.

Having had to open a number of new bank accounts in Europe recently I can say that the signing experience via these apps has become a super-slick 2FA style experience.

Although of course the underlying “money” is custodial, I don’t see any reason why having a “mobile device app as a signer” is a barrier to entry.

We are not trying to do something that a growing number of people will be unfamiliar with - especially in Europe - and if the banks are spending the money improving UX we should leverage that to compete.

The main issue is the fact that these apps use centralised messaging to achieve this between banking partners. I’m not aware of anything in our ecosystem that could replicate that - perhaps not even XCM because its a circular request: “I’m supposedly signing this message, to ask myself to sign something on another device that holds my keys more securely than the device I’m signing this from and the other device is expected to accept this signature as not having been compromised”. :man_facepalming:

Here is a video demo of the signing experience

1 Like

@chris Nik here, one of the architects of the Seeds Light Wallet on Telos/EOS, and now also of the Hashed wallet.

Signing with the signer app is the exact same thing as a 2FA request from a bank.

There are 2 possible flows

A - The notification flow

  • Website asks user to login using the signing app - signing app logs in by signing on the user identity and sending a signed transaction directly to the backend server. The backend verifies the signature with the chain. From this point on, the website knows the user is logged in with a certain device.

  • When the website wants the user to sign off on something, it sends a request to the signer wallet - exactly like a banking app, e.g. Revolut, does it. User signs on mobile app.

  • The wallet takes the transaction, and signs and broadcasts it - this does not go back to the website - the website is informed that the transaction has been executed via an optional callback in the signing request. So the signing request has a transaction consisting of 1 or multiple actions, and an optional callback. The wallet signs, and calls the callback when done. There are optional parameters to the callback too, ie, the transaction hash.

B - Directly signing a request via QR code (no login)

The website shows a QR code.

User scans with their phone
1 - if the app is not installed, it installs the app
2 - App starts and shows the transaction details of the QR code, user can sign or cancel
3 - On sign, app broadcasts transaction to chain, and optionally calls a callback like in case A.

While there is a lot of stuff happening behind the scenes, to the user, it looks like a 2FA request from a banking app - especially case A where they have signed into the website.

1 Like

That looks good. Are you able integrate that signer with any parachain?

1 Like

Yes, that’s the idea.

The next version of the wallet will have a network selector, then you all can let it loose on all networks (including a custom setting to set any endpoint, local, dev, etc)

1 Like