Cryptocurrencies as a transport layer; or, what’s wrong with Stellar

About two weeks ago Stripe published a blog post which articulated the promise of Bitcoin more succinctly than I’ve read anywhere else; in short, the post draws Bitcoin (or a derivative cryptocurrency) as the transport layer of a new digital economy. If you haven’t read that post yet, I encourage you to read it before reading this one—it does a good job of explaining concepts in a way that might even make sense to non-technical readers, and I will be building on those ideas in this post.

The Stripe post highlights an idea that I’ve harboured since the first time I heard about Bitcoin; basically, that its greatest value lies in its utility as a medium of exchange. Money moving around the world as freely as information does today. Transaction costs reduced to the point where it would be feasible for the New York Times to charge you ten cents for every article you want to read instead of shoving ads in your face. And consumers with the option of making international payments via their local credit union instead of the credit card and wire transfer oligopolies.

I started thinking about what a system which enabled that would look like. I didn’t get very far before, last week, Stripe announced its partnership with a non-profit organisation called Stellar which is trying to do the same thing. I have some concerns with their implementation, but more importantly (well, to me at least ;) ) after mulling it over for a day I’ve come to realize that I just fundamentally disagree with many of their design decisions. So this post is my attempt at explaining how I think using cryptocurrencies as a transport layer “should” work and how that contrasts to Stellar’s approach.

Design goals

The reason I disagree with the design decisions behind Stellar is almost certainly because we don’t share the same design goals. I can’t find any documentation of their design goals, but I will state mine here and refer to them later on. I’m intentionally trying to isolate the design goals to their most basic form—several further goals will stem from these but that is reflected in the text below.

  1. The system needs to fit into the existing “traditional” financial system in a well-defined fashion that is at least as easy for consumers and merchants to use as the current credit card and wire transfer systems. It should be something that could be used alongside current systems tomorrow; it should not require the development of a new ecosystem.
  2. If we choose a “gateway” based architecture (as described in the Stripe post) to accomplish design goal #1 then those gateways shouldn’t need to trust each other (trust relationships can *augment* the system but they should not be a prerequisite). Consumers and merchants will need to trust their gateways, though, as much as they trust banks/card networks/etc today.
  3. The scope of the system should be completely constrained by these design goals, ie. any feature that is outside of these goals is overcomplicating the system.

I think those three points actually encapsulate the end goal entirely for me.

Architectural overview of Stellar

From the perspective of end users (consumers/merchants, etc), Stellar implements the pattern described in the Stripe post. Basically, users interact with the financial system through a “gateway” which is responsible for coordinating their transactions with the rest of the system. So, for example, when consumer Bob wants to buy a shirt from he initiates a process which results in Bob’s payment gateway (eg. his local credit union) sending the correct amount of funds to’s gateway (eg. their bank, or a gateway that they operate independently, etc). This part of Stellar’s design is perfect, as far as I’m concerned. It’s pretty much the only part of their design that I agree with.

Underlying cryptocurrency

The payment gateway architecture leads us to design goal #2: we can require users to trust their gateways, but we cannot require gateways to trust each other. Currently, the only way to technologically enforce that requirement is through the used of a blockchain-based cryptocurrency, like Bitcoin. Stellar chose to create their own, brand new cryptocurrency for this purpose. I see that as a gross overcomplication of the problem space; instead of limiting the design to a payment protocol they have now accepted all the responsibilities around currency design, most of which are completely unrelated. I understand some of the problems Stellar was trying to overcome by creating their own currency (see below) but I think that would have been best solved as a separate project.

In my opinion, the payment protocol should be transport-agnostic. In other words, payment gateways should be able to choose which cryptocurrencies they wish to implement, and would only be compatible with other gateways who implement the same cryptocurrency. This places a larger technical burden on the gateways themselves, but it makes the network as a whole much more amenable to improvement. (Cryptocurrencies are still in their infancy; it’s reasonable to think we’ll find ways to make them better over time and that shouldn’t necessitate an overhaul of the entire payment network. Conventional cryptocurrencies may change over time, in a manner similar to the TLS ciphersuites.)

Time to verify transaction

This is, I can only guess, the main reason that Stellar chose to implement their own cryptocurrency rather than use a pre-existing one. Consensus in the Bitcoin blockchain is determined by mining nodes, whereas Stellar verifies transactions through a set of “special” peers (universities, governments, etc). The latter approach is faster; Stellar transactions can be verified within seconds while Bitcoin transactions can take significantly longer. I certainly understand the appeal of verifying transactions more quickly, but again I think the decision around those trade-offs is beyond the scope of this project. Instead, the risk around transaction verification should be swallowed by the payment gateways (and they already are, by mainstream Bitcoin processors like Stripe and Bitpay), who would be free to use external qualifiers (web of trust, etc) to do so. Again, the point isn’t that the Stellar currency approach toward verifying transactions is “wrong”, it’s just a problem that could easily be kept separate. Why combine problems when we don’t need to?

Responsibilities of gateways

Users (consumers and merchants) need to be able to trust their gateways, the same way they currently trust their banks. Stellar has a neat notion of defining how much you will allow yourself to be exposed to a gateway (eg. “my bank is allowed to spend up to $500 USD on my behalf”) which is great, but that’s something that payment gateways could and should work out individually with their clients.


Basically I wish Stellar was just a protocol. If cryptocurrencies are the transport layer of the digital economy, then we need to start building the application layer. The first step ought to be the “HTTP of payments”, and Stellar is trying to be way more than that.


Software developer, book writer, beer brewer :)

No Comments

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked