What’s Wrong with Counterparty

by Andrew Barisser (@abarisser)

Counterparty aspires to be the definitive Bitcoin 2.0 protocol. It brings a whole host of new features to the Blockchain. You can use it to create and manage assets, place bids, enact bets, and a wealth of exciting options. It introduces new levels of abstraction beyond mere currency. Counterparty is built on Bitcoin, which is the right thing to do. Finally, Counterparty has a sophistication which unambiguously demonstrates the intelligence of its creators: very smart people who have ambitiously tackled difficult problems. But despite all that, Counterparty is seriously flawed. While we should applaud the technical gusto involved with its creation, to actually adopt it would be a grave mistake. It is easy to be overwhelmed by the excitement of new toys and the weight of protocol minutiae. But buried deep within lie seriously misguided design decisions.

Counterparty seeks to do too much all at once. It is amazing to issue customizable assets and transfer them anywhere with the ease of Bitcoin. But did a bidding and order system have to be built in from the beginning as well? I’m not claiming that it’s not necessary. But it is also something that could have been developed as another layer on top. Or take the dividend function; Any cryptoequity schema should be capable of disbursing dividends. No question. But did dividends need to be their own internal operation within Counterparty? Why not merely use native Bitcoin and track assets?

Counterparty has overwrought functionality at every level. Capabilities that should have been built as layers above preceding capabilities, such as dividends on assets, have instead been forced into the same, tangled, overcomplicated protocol. Bets are another great example. Is it nice to have betting available on Bitcoin? Absolutely. But by including it in the core protocol, Counterparty has complicated a good feature, assets, with a much more challenging, experimental one.

The Tower of Babel

It is better to build in simple, minimalistic layers that are each very good at one thing. One feature is built upon another. Introduce assets. Build tools that send dividends in pure Bitcoin. Keep them separate and simple. The same functionality that Counterparty strives for could be better accomplished by separate, compatible layers. Consider the parallel with software libraries and with the Unix philosophy. They each have a discrete task and are mutually compatible within the same programming language. They are made by different people with their own styles. In the marketplace of ideas, different libraries by different people will win out. The optimal solution is to let libraries compete in parallel and then to take the best set of them. Imagine if dependencies, controlled by a central team, had to be installed all or nothing; it would be a nightmare.

For basically every aspect of Counterparty functionality, there is an equivalent solution in Colored Coins and in side-chains. It was never necessary to do everything at once. In attempting to do so, Counterparty introduced a deeply antithetical and unwanted element: a separate native currency, XCP.

XCP, paying to unlock features

The Counterparty currency, XCP, is required to use certain features. This makes it an unwelcome and unnecessary variable. While it is not needed to access all Counterparty functionality, that is not much consolation. For example, if you want to create a new asset, you must destroy 0.5 XCP. That is greater than $1 at current prices. This seems ridiculous on several levels. First of all, the XCP monetary supply is fixed. For currency to be systematically destroyed, and for the entire monetary base to be in absolute decline, are needless, distracting distortions. Why should I even have to pay $1 to create an asset? Where did that 0.5 XCP price even come from anyway? It wasn’t organically determined in a market. It was set by that most hateful of four letter words, by fiat.

The mere existence of XCP means that, to use certain features of Counterparty, I must look at the XCP/BTC ticker price. Whole websites exist to track this price, with people offering bid/ask liquidity like in real markets. But to what purpose? Why should I be exposed to the distraction of yet one more ticker price to do something as mundane as create an asset? Other protocols don’t require it. It is a barrier to entry that was never needed. It is an obstacle, an eyesore on the protocol, a bad idea from the beginning.

I suspect that XCP was created as a technical convenience. As an altcoin, albeit one on the Bitcoin Blockchain, it may have its own set of governing rules, in which capabilities such as escrow are possible. Yes, the separate rules of XCP enable features on top of Bitcoin. But separated as it is from Bitcoin by a fluctuating market price, XCP, for all intents and purposes, might as well be another NXT on another blockchain entirely. Having to resort to an altcoin, whatever blockchain it resides on, to add functionality means we have failed.

Consider how arbitrary Counterparty’s design process is. Who is in charge? Basically 2–3 guys. When is the next time they will commit a hard fork? It’s totally up to them. Look how many different client versions there have been in a short period of time. You could say that it could be forked independently at any time. The complexity of the protocol suggests that

  • A serious hard fork is only a matter of time. Perhaps it will be the next time there is disagreement over one of the fully arbitrary XCP ‘fees’, or any of the countless arbitrary details within.
  • Everything will break all at once if there is a fork (or bug). No compartmentalization means no safety in redundancy. And we’re stuck with centrally foreordained solutions.
  • If there is a fork, XCP will crash massively due to the loss of confidence.

Because it is so overarching and so centrally administered, Counterparty is brittle.

What Counterparty Should Have Been

Counterparty could have taken one of two superior, alternative routes. If it had wanted to preserve the baked-in complexity, refusing to modularize, they could have built sophisticated two-way sidechains with all the desired features therein. With permanent, fixed exchangeability between BTC and XCP, XCP would not be an altcoin so much as a surrogate for Bitcoin with enhanced functionality. There would be no price ticker to worry about. Granted, sidechains are very new and non-trivial to implement. But it would have been a clean and sophisticated solution.

Another approach, the one I prefer, would be to build features in discrete, minimalistic steps. One addition would not require another. For instance, we could try several implementations of betting (with oracles, multisig, or sidechains) without breaking a solid implementation of assets. There could be more diverse community input, more modularity, more choices. And there would be a less monolithic organization dictating protocol changes and hard forks at whim.

At all costs avoid resorting to a separate altcoin currency to achieve features. Besides the inelegance and tedium of transacting into a separate currency, XCP introduces a moral hazard. XCP holders are incentivized to propagate the Counterparty protocol to enhance the value of their holdings. Regardless of whether Counterparty’s approach was the best solution for users, perhaps it was the best tool for aggrandizing its founders. While BTC was burned to create XCP (in an unholy ritual), who is likely to be holding XCP and to win financially from its adoption? Surely it must be the founders. XCP, besides being poor design, was probably born as a vehicle to monetize Bitcoin 2.0.

We’re all excited about Bitcoin 2.0, crypto finance, and similar sophisticated tools. There’s a wave of innovation coming. So many brilliant people, including the Counterparty folks, are working in this area. But let us not conflate our excitement for cryptoequity with Counterparty itself. As we inscribe valuable financial information in the Blockchain, it is imperative to choose the right design from the beginning. Let us not settle for an imperfect solution, involving an altcoin, because it was technically convenient. The decisions we make now will ossify into tomorrow’s status quo. So let us take the hard steps to do it right now, while we still have time. The real, long-lasting solution needs to be a winner. Make it modular. Make it lightweight. Make it on Bitcoin, or a two-way sidechain linked to Bitcoin.

Simply put, we can do better.

Full disclosure: I work on Colored Coins at Assembly. There are a lot of good ideas in the community. Check out:

Assembly Coins

Open Assets


among many others.

If you enjoyed this, follow me at @abarisser