BitShares - probably the first self-sustaining DAO

BitShares - probably the first self-sustaining DAO

BitShares Crypto 2.0 Delegated Proof of Stake incentives Proof of Stake

For over a year, the Bitcoin world has been intrigued with the concept of Decentralized Autonomous Organizations - quasi-corporations following known and predictable set of business rules dictated by the software itself. While in the future we might have AIs running everything, for now human involvement in software development and other functions necessary for the DAOs to sustain themselves.

Vitalik Buterin's Quadrant Chart for Classifying DAOs

While most cryptocurrencies do form a quasi-DAO, to the best of my knowledge BitShares appears to be the first system to be a fully self-sustaining DAO. Lets explore why this might be the case.

What does a DAO need?

While there are a lot of characteristics a DAO has, we should figure out what a DAO, or any decentralized software-based system wants and needs.

While some might see this as anthropomorphizing a non-living piece of software, we can probably agree that any DAO-like system wants to first of all fulfil the role it was created to perform (in the case of cryptocurrencies - to facilitate transfer of wealth between individuals), and secondly - the system would want to accomplish anything to allow it to continue its first role as long as it is needed.

To accomplish the latter goal, the software needs to be updated, new blocks need to be created, and the system itself needs to become more ubiquitous.

Now, how can a DAO fulfil its needs? Well, it can reward the people that work on the system. If we're talking about cyrptocurrency systems, money is usually a good motivator.

Examining the incentives

We already discussed the problem some systems have with incentives in a previous post. Here, I would like to discuss how various examples of cryptocurrency systems reward its participants.

Bitcoin is probably the most notable early example of a quasi-DAO. It rewards its miners with a block reward and transaction fees, ensuring new blocks are created for years to come. Bitcoin however does not create a direct incentive for software developers to update its software, or for businesses to offer new products on the platform. Sure, there are plenty of non-direct incentives - anyone holding BTC is incentivized to make the value of BTC appreciate so they stand to profit, but that happens external to the Bitcoin software itself.

In a system like Ripple, where the fees are burned and there is no token creation, only the XRP holders are indirectly incentivized to keep the system going - the validators are not paid, nor are the developers.

When looking at a proof-of-stake systems like Peercoin, we have the coin holders that are incentivized to create new blocks, but again, no other direct rewards go to anyone else.

Now, when we look at BitShares and its Delegated Proof of Stake, we see something different. While it's still the block "miners" / delegates that get the reward, who gets to be that delegate is a different story. Unlike proof-of-work or proof-of-stake, anyone that the BitShares coin holders elect can become a delegate and be rewarded for it. If the software needs updating - the core developers will be voted in and paid for their work. If the system needs evangelists - the right people for the job will get the rewards, etc. As it stands, it looks like the system can be fully self-sufficient using this simple reward system.

So while the DPoS implementation in BitShares might not be without its flaws, the concept does lend itself to solving a lot of the problems a cryptocurrency system might have in a simple fashion.

Lastly, this process is no longer unique to BitShares. Stellar introduced a similar method for distributing its token inflation.

Conclusions

While there are a lot of systems out there that act like a quasi-DAO, BitShares seems to be the first one to become fully self-sustaining due to its Delegated Proof of Stake.

Shipping without incentives and features

Shipping without incentives and features

Bitcoin Factom incentives Mastercoin Omni Ripple tokens

Recently I was doing some research into Factom, a new project that aims to embed a lot of data into the Bitcoin blockchain and create a "proof of existence as a service", among other things. I stumbled upon some criticisms of the software (Google Cache link, as the original was taken down). One of the crucial features missing from the Factom code at the current time appears to be the lack of incentive for nodes to store any data after it is embedded into the Bitcoin blockchain. Pondering this for awhile, a few similar issues with other systems came to mind, and thus I'm writing this blog entry on various Bitcoin-related software that launched without some important features or incentives.

"Convenient bugs and arbitrary features" is also a recommended reading related to this topic.

Red balloons - Bitcoin is not without its flaws

When I was doing research for my master thesis on Bitcoin, some researchers from Microsoft and Cornell University released a paper called On Bitcoin and Red Balloons, where they pointed out the Bitcoin nodes have no incentive to propagate transaction information through the network, and miners have all the incentive to actively withhold that information.

The gist of the research is that while anyone creating a transaction has the incentive to propagate it through the network (they want the transaction to be put in a block, so they spread it to everyone), miners have the incentive to include paid transactions into blocks (to earn fees), Bitcoin nodes have no incentive to relay the transaction information. They are not getting paid to do so, nor do they benefit from the transactions they transmit directly. Moreover, if a miner knows of a transaction with a fee, they benefit from not broadcasting it - this way it is less likely to be mined by their competitors and they are more likely to earn that particular transaction fee.

One can argue, however, that every business built on top of Bitcoin has the incentive to run a full node that relays all the information. While they don't benefit directly, the abundance of full nodes makes the network more resilient to attacks and more distributed. What benefits the community at large is also beneficial to the individuals in some way.

Mastercoin - a token without a purpose

Back in the day when Mastercoin launched (and has since re-branded into Omni), my biggest question surrounding this technology was - "what are mastercoins used for?". In the Bitcoin space, you would use bitcoins to pay the transaction fees. In the Mastercoin space, well, there wasn't a clear use for mastercoins. Sure, the project itself benefited from the crowdsale to fund the development of the protocol, and some people earned some pretty penny speculating on the price of the coins, but there was no immediate use for the tokens themselves. There were no mastercoin-denominated fees in the system, the transactions instead paid the standard Bitcoin transaction fees. Only much later did the developers include a clear use case for the tokens - to burn them for crowdsales. A little bit of an arbitrary feature in my opinion, but at least it is some feature.

Ripple validators - a big burden with no reward

In a similar vein to Bitcoin's lack of incentives for running full nodes, the Ripple network provides no incentive for network validators. A validator is similar to a miner on the Bitcoin network - they process all the transactions taking place on the network and create new ledgers. While mining bitcoins is a computationally-intensive task due to proof of work, the Ripple network is more heavy on the disk space (full network history taking up 100-500GB of data at the moment).

Unlike Bitcoin however, Ripple fees are not paid to the miners / validators, they are instead burned. Similarly, Ripple has no coin distribution schedule - all the XRPs have been created in the genesis ledger. This leaves validators with no incentive for a potentially burdensome effort (most of them are currently run by Ripple Labs last I heard).

There are two approaches to solving this issue however. One is the idea that the Ripple gateways should also run validators, as they are the ones earning the most money from the network operating. The second approach could build on top of Stellar's token creation - the validators can be compensated by the users of the networks for their contributions with newly minted stellars.

Factom - pay to save, never load

As mentioned in the opening paragraph, it appears that the Factom network allows its users to save any pieces of information into the network for a fee, but fetching the data in the future carries no cost and thus no reward for the nodes to carry out that request. If someone decided to abuse the network, they could try flooding it with a lot of requests similar to a denial of service attack - honest nodes would be overburdened with having to provide a lot of data, while lazy nodes that wouldn't even attempt to provide the information would be better off.

As such, it appears that the Factom network will need to expand its fee and reward structure to provide incentives for nodes to store information as long as it is useful, similar to how MaidSafe is supposed to work.

Branded coins - start with a purpose

I heard a few similar pitches - a company wants to release a new, branded coin and tie it to their service. They usually have some grand vision of how everyone will want to use their coin since they will be able to spend it in their system and pay anyone just as easily as they do with Bitcoin. Sometimes it's customer rewards for shopping, sometimes it's some coin to raise brand awareness. However, quite often such pitches lack one crucial thing - why would anyone want to use the branded coin over Bitcoin? If you say, have a payment processor that accepts Bitcoin and their branded coin, I personally see no reason to use the branded coin over Bitcoin, nor to hold it any longer than it takes to convert it back into BTC. Even the usefulness of presale tokens can sometimes be dubious.

In the end, a branded coin needs to serve some purpose other than just existing for the sake of it.

Conclusions

There have been a lot of projects in the past that have launched without all the necessary features or without proper incentives to support all of the functionality. While we can expect some level of altruistic behaviour from the people running the software, a well-run system shouldn't rely on altruism alone - either you pay to use the resource, or you lose it.