Counterparty vs RGB vs TARO
I recently attended a Historical NFT festival, what are Historical (or Vintage) NFTs? in layman's terms they are the NFTs that were around before NFTs became “cool”. At this festival the Counterparty protocol seemed to be the main area of focus as arguably it was really the first NFT platform on bitcoin back in 2014 (there were other protocols but Counterparty was the first used to mint what we now call NFT art rather than utility or financial tokens).
Fast forward to 2022 and we have two new protocols launching on the bitcoin network namely RGB and a similar protocol called TARO.
RGB and TARO are largely the same (TARO was previously called CMYK as a kind of tease to RGB) and they are not my area of expertise so I won’t contrast them in too much detail, however I would like to compare Counterparty to these new Bitcoin token 2.0 protocols and ask why make something new?
Counterparty Summary
Launched in 2014, Counterparty emerged amongst other token protocols such as colored coins and Mastercoin (now known as omni).
Colored coins seemed to be created with ideas such as “tokenizing shares of gold on the blockchain” in mind. Mastercoin was quite corporate and not easy to use without collaboration from the company behind it. Counterparty launched as an open standard with an easy to use wallet that everybody had access to making it ripe for adoption amongst casual bitcoins in the community.
The original founders designed it with financial services in mind, such as using tokens to represent shares in a company, however there were several legal issues and complications around doing this so they ultimately left the project to form a more corporate structure (symbiont.io). This left the protocol in the hands of the community who started to use it for “community” projects such as RAREPEPE, collectibles art, etc.
How did Counterparty work?
Unlike colored coins which tracked Satoshis, Counterparty is a data layer on top of bitcoin.
Another way to explain it is with colored coins you would say “this satoshi represents this bar of gold” then in order to transfer that bar of gold from Alice to Bob you would just send that Satoshi from Alice to Bob. (technically not this simple but its good enough for a medium post)
However if you wanted to buy a coffee and accidentally sent that same Satoshi to Charlie the barista, then Charlie would then have that gold. (or at least Satoshi representing it)
This meant one had to be careful using colored coins as it was easy to accidentally send a token to a receive who was not expecting it, could not see it nor could return it.
Conversely in Counterparty you would have to make a special Counterparty transaction to transfer ownership of a token. The counterparty node would then parse this transaction data out of the blockchain and update a ledger/database that lived in the Counterparty node.
This was done using OP_RETURN a way to store arbitrary data in a bitcoin transaction and thus into the bitcoin blockchain.
The OP_RETURN data would say something like
SEND 1 RAREPEPE to ADDRESS X
You would put this OP_RETURN data into a bitcoin transaction and as long as you signed that transaction with they key of the address that currently held the RAREPEPE the token would be transferred to the new address stated in the OP_RETURN data.
An advantage of using OP_RETURN is that it mean full nodes not interested in Counterparty would not need to store nor validate this data and could prune it out of their node.
Why create RGB/TARO if we have Counterparty?
This is a fair question, as of today Counterparty seems to have more features than RGB and TARO and has been running since 2014, so why make a new protocol?
I think there are several reason why a developer would prefer to make a new protocol from scratch rather than build on top of an existing one.
Motivation
I think a big reason is just that developers like to create their own project and have their own “baby”. It’s more motivating to work on your own idea rather than maintain and improve an existing project.
Technical
Starting a new codebase lets you create good code using the latest learnings and technology, it can be messy shoe horning new paradigms into an existing codebase. There were also many developers who looked at the Counterparty code base and just though it was poor. Especially given todays standards and new technologies in cryptography.
Scalability
As RGB/TARO uses client side validation (explained later) it inherently scales better as each user does not need to store the history of all tokens.
Ignorance
Many developers either didn’t know about Counterparty or thought that it was dead
Counterparty Token
I think this is an important factor. Bitcoiner’s in general don’t want to work on a protocol that has its own Token, which Counterparty did called XCP. I feel this forever tainted the project and in hindsight I think it would have been best to never have issued it.
However I would argue it’s not quite the same as other protocol tokens as
a) You don’t actually need it
You can make Counterparty transactions, issue assets, use the decentralised exchange without ever touching XCP and just using BTC
b) It was fairly sold
Unlike other protocols that did an ICO enriching the founders, XCP was distributed via proof of burn, meaning you had to burn bitcoin to get XCP. This meant the founders had to spend their own bitcoin to get XCP and thus could not just enrich themselves with a pre issuance.
What was XCP used for?
Although you don’t need XCP to use Counterparty it is required to issue assets with custom names. Counterparty asset names are unique, similar to URLs, so you have the same issue as URL squatting i.e. an entity will pre buy up INSERT_POPULAR_NOUN.com
In order to mitigate this in Counterparty you had to have XCP inorder to issue custom asset names, such as SATOSHI coin or FREEDOM coin.
Another small requirement for XCP was to use the Counterparty DeX (decentralized exchange). The DeX allowed p2p non custodial trading of Counterparty assets. i.e. I could make a sell order trading 1 RAREPEPE for 1 SATOSHICARD and simply broadcast that order to the bitcoin blockchain, if some one made a sell order trasing 1 SATOSHICARD for 1 RAREPEPE the order would automatically be fulfilled and the assets transferred.
Thus in the case where a user wanted to trade a token for another token, XCP was not required, however trades often do better when assets are not bartered 1 for 1 but rather bought and sold for a liquid base currency. Ideally this would be BTC but technically it was not really possible as bitcoin doesn’t exist on the Counterparty protocol layer only Counterparty assets do hence the idea was that people could trade assets for XCP and then sell that XCP on an exchange for BTC. (Ultimately the base asset ended up being PEPECASE and not XCP!)
Why is RGB/TARO better than Counterparty?
Apart from the fact that it doesn’t have its own token giving it a “clean” image there are many technical innovations that make RGB/TARO compelling.
I believe the main technical merit is the way data is stored.
As mentioned before Counterparty uses OP_RETURN to save Counterparty messages updating its ledger/state in the bitcoin blockchain. As it uses OP_RETURN regular bitcoin nodes need not parse nor store this data however if you run a Counterparty node you do have to store a large ledger containing the state of all Counterparty transactions.
RGB/TARO use client side validation.
This means the ledger or state of the network is not stored in the bitcoin blockchain rather each user needs to store this data for themselves off chain in their own database.
A hash/proof of this database is stored in the bitcoin blockchain and via a clever use of Merkle Trees you only have to store the data of tokens you wish to interact with.
For example in Counterparty if I am Alice and I send Bob 1 RAREPEPE, then Charlie sends David 1 SATOSHICARD, I have to store record of Charlie and Davids state even though it has nothing to do with my transaction to Bob. Charlie and David also see my transaction to Bob making it less private.
In RGB/TARO I could ignore any data regarding Charlie’s transaction to David. If David then sent the SATOSHICARD to me Alice I would only need to store and validate the data at that point.
This ultimately makes RGB/TARO more private as 3rd parties will not know about my transaction until I include them in it. It also means I need to store less data. This hash/proof is effectively indistinguishable from a regular bitcoin signature when it is included in the tapscript, meaning that RGB/TARO transactions look like regular bitcoin transactions. Counterparty transactions are transparent as they use OP_RETURN and thus can be (and have been) censored by nodes and miners.
(note: it seems that RGB also lets you use OP_RETURN to store the hash instead of tapscript, however it is just a generic hash and cannot be differentiated from other OP_RETURN hash based protocols such as open timestamps)
RGB/TARO being new projects (with VC backing) may also be able to excite and fund more developers to work on the protocol ultimately making better tools, slicker wallets etc
Many companies funding and building out Counterparty since 2014 have since gone bankrupt or moved onto chains such as Ethereum leaving the development pace slow with the ecosystem largely relying on community donations.
(However the recent 2021 NFT bubble did see some money find its way back into Counterparty development with several devs going “full time” on the project and new companies building on top of it)
Why is Counterparty better than RGB/TARO
One downside of the client side validation in RGB/TARO is if I lose my data and nobody else has a copy of it I lose the ability to make any further transactions and would effectively lose my assets.
With Counterparty the state can be re-parsed and computed from the bitcoin blockchain at any point.
Subjectively I would also argue that the asset names being unique make Counterparty more compelling for “collectibles/NFTs”
Feature wise the Counterparty protocol is ahead of RGB/TARO allowing users to issue, send, receive, trade on a DeX, do dividends, batch send, create dispensers and many more etc
Counterparty also has an existing eco system and community which has built up over the years.
Why do RGB, TARO and Counterparty all suck?
Personally the problem with all these proctcols is they require an onchain transaction to transfer ownership of non fugible or illiquid assets.
You can technically make lightning networks with the fungible tokens a built on top of them (such as stable coins). However as far as NFTs are concerned I don’t think the kind of uses cases that people imagine being useful will be possible. One example is using NFTs for gaming. Popular games do thousands if not hundreds or even millions of transactions a second, if each transaction requires an on chain bitcoin transaction this would not scale and would lead to the relatively few users who could use them having to pay large fees. Personally I saw this happen in 2017 when I had games using Counterparty with players having to pay $10 in fees to trade a $1 game item and waiting days for it to confirm.
Not much has fundamentally changed with RGB and TARO in this respect, yet, RGB does allow batching (Counterparty as well) but I am hopeful that these protocols may find better homes in future possible bitcoin side chains projects.
