Private key-less, gas-relayer for HOPR Nodes

Some time ago I shared the concept of a browser-based private key used to quickly onboard a user. The idea was simple: create a dumb private key during the onboarding of a DApp so users wouldn’t need a web3 provider to start using the app right away. Using a Gas Relayer like OpenGSN anyone could use the app even if it had no gas. Here’s the overview (the initial link has a full breakdown).

In a similar, a HOPR node generates a private key, but this has the following likely unwanted side effects:

  • Connect it to an existing web3 provider like MetaMask (so I can’t use my own account, ENS, etc)
  • Forces me to fund the key every time I start a new node (as export or import are not available)
  • Withdraw all the funds there’s an upgrade.

What I am proposing is that we built a version of HOPR Node which is private key-less. To be more accurate, we would still need a private key, but this would be mostly used to sign off the transactions against a relayer which would be the actual individual paying the transaction. That way,

  • No funds need to be requested or checked against the current key, it only needs to be whitelisted somehow against a gas relayer.
  • As keys are disposable and irrelevant, they do not need to withdraw funds.

As a minor inconvenience, we would need to modify the HOPRChannels.sol smart contract so when payments are settled, we can pass to which address the HOPR tokens will be sent to. There are a few additional nuances, but in an ideal world, this would result in users being able to use their own MetaMask, which upon connection deploys a gas relayer any random key can use upon an adequate whitelisting process.


:clap: good

Thanks for the suggestion! Remember, if you’re finished and would like to make this an official proposal, please edit the title to include “[Proposal]”. It will then be flagged for moderation.

More information on the validity guidelines and submission process can be found here:

Upon thinking about the workload this would entail, particularly on the current state of affairs of the protocol, I’ll be dropping this one out.