Reputation vs. Tokens


Readers unfamiliar with Reputation in DAOstack should consider reading this explainer article .

The topic of decentralized governance is becoming increasingly popular, and with it, the topic of decentralized voting systems. For now, DAOstack’s decentralized governance infrastructure is mainly focused on supporting Reputation-based voting. In this piece, we explain the main differences between Reputation and tokens. We then discuss the fungibility property and its defensible effect on vote buying. Finally, we will review different governance models one can explore with Reputation or token-based voting.

Formalizing the differences

The most common thing encountered when we discuss Reputation vs. token-based voting is a misunderstanding of what a token is, which leads to an understandable confusion between the two. In some talks, we’ve even heard the unfamiliar term “Reputation tokens.” We believe that some of the confusion is related to the Augur project naming their token “REP,” and other cases of the word Reputation as used in the blockchain space. Let’s clarify what we mean by tokens and what Reputation is in DAOstack.

We believe a token on the blockchain should hold these two properties:

  • A token cannot be taken away from its owner.
  • The owner can transfer the token to anyone else, without requesting permission.

Note: Not all “tokens” hold these two properties. For example, the Bancor team can disable all transfers of the BNT token . They can also selectively destroy (burn) tokens of any user they choose . Others may disagree, but since BNT does not possess the above two properties, we do not consider it a token.

Now that we understand these two properties of a token, we can understand Reputation better in comparison. In DAOstack, Reputation has the following properties:

  • Burnable: namely, it is not really “yours.” It is yours as long as the owner of the Reputation system does not choose to take it away. With DAOstack, there is a hidden assumption that the Reputation system owner is not a single person, but rather a DAO, whose actions are controlled by the DAO’s Reputation holders.
  • Non-transferable: namely, an account to which some Reputation was allocated can neither transfer nor burn it.

These properties create a very interesting structure. A Reputation-holding account holds a certain right — in our case, a voting right — in an organization. However, this right is far from absolute: at any point in time, the organization can refute it by slashing the account’s Reputation. You can imagine this might happen if a stakeholder acts against the organization’s rules, whether hard rules enforced by code or soft rules enforced socially. Furthermore, the non-transferability of the Reputation makes it effectively non-fungible, so the slashing threat on this account has no expiration date. Consequently, there is no statute of limitations: a DAO can slash an account’s Reputation due to an offense committed five years ago.

Vote-buying

In token-based voting, vote-buying is considered a feature. Our Reputation-based systems try to prevent or limit vote-buying. Although it is not trivial to map how effective these measures are, we attempt to do so here.

As a start, it is important to distinguish between trusted and trustless vote-buying. A trade is trusted if the seller and the buyer can depend on each other to be honest, a trust that generally comes from some kind of social relationship. If the buyer and seller cannot be certain the other will behave honestly, we call that trade trustless.

In the case of vote-buying (Reputation-trading in our system), our version of Reputation provides a strong defense against trustless Reputation-trading. The most naive example is someone selling his private key. While there is no mechanical way to prevent the selling of private keys, since the Reputation cannot be transferred, the buyer will always have to trust the seller for not using the key and voting with it. This type of vote-buying clearly requires trust.

Moreover, a DAO can implement a policy of stripping Reputation from any address found to have sold its private key. If the seller of a key is dishonest and keeps some evidence of the sale, he can then reveal this evidence, and the DAO will strip the address’ Reputation, effectively confiscating the buyer’s purchase. DAOs can also adopt policies to reward sellers for revealing these records, further discouraging this type of trading. Therefore, people seeking to buy votes in a Reputation system have a strong reason not to trade trustlessly.

Blockchains are typically presented as a solution to this problem — making trustless trading trustworthy — but they do not get around this Reputation-stripping mechanic. For example, one might argue that safe, trustless vote-buying can be achieved on the blockchain using a key escrow. If one owns a contract that holds Reputation (as an opposed to a wallet address), he can indeed use such an escrow to sell the ownership of that contract securely, either permanently or for a finite time. This blockchain escrow does nothing to prevent the seller from keeping proof of his former ownership of the contract in secret, though, which means this type of sale can be punished by the DAO just as easily.

Whether one is selling private keys or transferring control of contracts, there is no way to truly prevent trading if the buyer and seller establish trust that the seller will never betray the buyer. However, setting up such trusted trades is very difficult when any ability of the seller (or buyer in the case of buying for limited time) to keep sales records prevents trades from operating trustlessly, as is the case in our Reputation system. Furthermore, successful public markets typically require a high level of trust (even in cryptoeconomics), which means active public markets for Reputation will be challenging to get going. Without active markets, and considering its non-fungibility, Reputation price-discovery will be almost impossible.

It is clear that the solution presented by Reputation is not perfect, mainly because Reputation-stripping is in some sense manual. However, if the DAO sets a clear policy to slash all the Reputation of those attempting trades and to reward Reputation-sellers who report their sales, vote-buying can be effectively restricted.

Bribery

Th ere is another type of attack on decentralized governance that does not include buying voting power, but rather tries to bribe voters to vote in some direction. This type of attack is actually more effective on-chain, as an attacker can guarantee the bribe via a contract. One example is a contract that holds funds and reads the votes on a certain proposal after it is finished, then pays those who voted yes pro-rata. One might even consider a more brutal attack, using a contract that makes a proposal in a DAO for the DAO to give all its funds to this contract. If the proposal passes, the contract will split the funds between all the voters who voted for this proposal pro-rata. To make the attack even stronger, the contract can split the reward not just pro-rata but also with an ordering weight such that earlier voters get more.

Bribery attacks are very efficient, and in the case of token-based voting, they are almost impossible to defend from. In reputation-based voting, it also very hard to defend against such attacks, but there are some lines of defense one can take. For example, if the counting of the votes takes place at the end of the voting period instead of at the time each vote is placed (which would require some off-chain computation), DAO members that spot a bribery attack can try to take the Reputation from voters who vote for such a proposal, effectively negating their votes.

Decentralized Governance

Reputation-based governance attempts to align long-term incentives. In token-based voting, one can buy tokens, vote, and sell the tokens, which dramatically shifts incentives. Token-voting can even be automated such that contracts auction their voting right for each proposal. Reputation, on the other hand, can only be earned in ways that the DAO has decided on, and is very hard to sell, as described above. Reputation-based voting, then, gives Reputation holders longer-term control over the direction of their DAO — they can freely choose what to incentivize with Reputation rewards.

One must also consider governance structure when choosing between token or Reputation-based voting systems. In this case, the governance structure refers to the types of decisions that are taken and how frequent they are. Token-based voting might do well when the frequency of decisions is low, as it is with the shareholders of most public companies. When decision-frequency is low, decision-makers are likely to maintain a high participation rate, making buying enough votes to sway a decision prohibitively expensive. Frequent votes with token-based voting will probably be much easier to manipulate, however, since collective attention will be stretched thinner, meaning a smaller proportion of votes must be bought to sway a decision.

Token-based voting also does well with objective questions, e.g. reporting the temperature at a specific place and time, as the right answer acts as a strong Schelling point (this is the principle behind oracles). Faced with non-objective questions such as if the organization should do A or B, however, token-based voting may perform poorly, since there may be no strong Schelling points.

Governance solutions that use Reputation, such as the Holographic Consensus framework developed by DAOstack, try to be scalable enough for frequent decisions while also working for non-objective decisions. This is accomplished by allowing small groups of Reputation-holders to make decisions decided by local majority and securing the system by turning any decision not in agreement with the global majority into an economic arbitrage. In addition, because buying voting power is much more difficult than in token-based voting, Reputation-based voting should be resistant to malicious vote-buying even with low participation rates from Reputation-holders.

There are also other governance options that are worth examining and researching, such as token-based voting with a long-term locking mechanic. That is, tokens could be made non-transferable by moving them into a locking contract in exchange for voting rights. There are even more radical solutions, such as futarchy, which has briefly been discussed as a future DAOstack implementation. We invite researchers to contribute their own ideas to the DAOtalk Research forum.

Researchers and developers can easily add new governance methods, such as token-locking or futarchy, as schemes within the Arc Platform , the modular smart contract library by DAOstack.

Decentralized governance is history in the making. It is hard to predict what solutions will be adopted. Thus, it is important to keep an open mind and try to build systems that will be as modular and adaptable as possible. This is the design philosophy guiding the DAO stack, and we hope to see many governance systems powered by it with an equally diverse set of use cases in the future.

4 Likes

Good article!

I just think that part about defending bribery is not convincing to me. The argument is that reputation can be reduced before a bribe is successful. I would imagine that stripping someones reputation requires a somewhat high approval. If that can be reached the DAO could probably directly just decide to reject the proposal and slash those who voted for it.

The issue is that with trusted hardware people can make a commitment to vote for a bribe attack “ONLY IF” a majority for the bribe is reached. Furthermore the participation in such a scheme will only be revealed IF it reaches the critical mass. Unless there is “off-chain reputation” (basically additional “loss” from participating it is always rational to participate as early as possible - see Dark DAOs:

1 Like

Thanks @koeppelmann :slight_smile:

I agree with you that the last part is not convincing enough. It was not part of the original piece, but while I was writing the post we had a fierce discussion over on-chain bribery attacks in the office, and I felt I have to at least mention it.

I think @matan is writing an elaborated post just on this issue.

1 Like