ElectrumSV hosted services roadmap

The sooner ElectrumSV supports hosted services, including Paymail, the better. We’re headed in the right direction, but there’s a lot to do. This article is intended to lay out the path towards the implementation of those hosted services, and illustrate what’s involved.

There’s a lot of decisions that have to be made, and unsolved problems. But that’s okay, the first version doesn’t have to be perfect. It just has to be good enough, and the sheer potential of even that will allow us to move forward and take advantage of it.

Laying out the path

Exchangeable identity

It all revolves around identity keys, but we’re not going to build a system to catalogue identities on-chain, at least not in the first version. That’s a lot more work, and it’s better to choose an achievable starting point. So, let’s start with P2P identities. Your friend shares their identity with you, you share a friend of a friend’s identity with them. Go to someone’s web page and obtain their identity from that. Have them send it to you in your email. That’s good enough, and we can start from there.

Identity-based authentication/encryption

Once another party has your identity key, and you have theirs, then you can establish an authenticated encrypted channel between the two of you. This can be used for when ElectrumSV connects to a host that provides some of the services it needs, and even for two wallets to exchange messages. And the inter-wallet channel can even pass through the service channel.

The service’s identity key can be obtained from the host’s DNS record, in much the same way that Paymail looks up DNS records.

Payment templates

The path forward for Paymail is delivery of a transaction to a recipient at their Paymail host. For hosted wallets like HandCash, Centbee and MoneyButton, they deliver all transactions to their users anyway, so this is more of the same. But for a standalone wallet like ElectrumSV, a transaction is just another message that they retrieve from their mailbox.

How can someone send a payment to a new contact, without prior communication and without reusing addresses? The simplest way is with output templates and a payment policy. I shouldn’t have to repeat that just because you send someone a transaction does not mean they have to accept the payment, they can just ignore it and your message. Or they can waive the payment, and proceed with your message. The policy would ensure a range of things from structuring requirements for privacy reasons, to whether the payment required a valid sender, to perhaps even a payment master key to derive payment destinations from. There’s some overlap here with the DID specification, and basing this on that prepares for the longer term plan of on-chain identity.

The ElectrumSV-friendly Paymail host would also use these to hand out payment destinations. Then it’d pass the payment derivation metadata, along with any known sender the given payment destination was provided to, as an internal message in the hosted identity’s mailbox.

Hosted mailbox RPC API

This is going to be quite simple. Listing messages with paging. Ability to retrieve a message. Ability to delete a message. From there, it comes down to how we structure the messages. This is all done through the ElectrumSV to hosted service channel.

Posting messages

We can start with the hosted service receiving messages on a Paymail API.

ElectrumSV message handling

This will be integrating the already prototyped ElectrumSV to service host channel code. Then extending it with what format messages ElectrumSV will handle, and how it handles them.


Should someone be able to fill your mailbox with something resembling payments or messages? How do you prevent it? If the messages are encrypted and the mailbox host can’t identify noise from signal, then how can it prevent the noise from obscuring the signal? It might be argued that if the mailbox does not enforce payment in some way as part of receiving a message, then it is doing it wrong. The payment might be part to the service, part to the recipient and well.. the details can be worked out as we get there.

The roadmap

Order will change as appropriate.

Final thoughts

There’s nothing impossible on this list. It’s just a matter of time. If you want to discuss any of this, and potentially get involved, feel free to get in touch.

Before I can seriously get into any of this, the outstanding UI work for the 1.3.0 release needs to be completed, and polishing of that release under way. But bits and pieces will be gradually completed as I switch between the tasks when I need a distraction.


Web site and downloads

Official ElectrumSV web site: electrumsv.io
Official ElectrumSV web site downloads: electrumsv.io/download.html


If you need some assistance with something, please submit an issue at the following link. But please, fill out a template otherwise we will not have the information we need and you will have to wait longer for assistance.

Report an issue: github.com/electrumsv/electrumsv/issues

We do not provide support over Twitter, and will request you submit an issue. Support over twitter is much more difficult, and we prefer to avoid it completely.


You can reach us for discussion in one of two possible locations.

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store