EOS New York has recently sparked a discussion on risks of EOS token smart contracts (read the post). In this article they highlight the risk that 8/10 of the top tokens on EOS have a single owner key which controls. EOS New York is proposing that the token can be created from the contract deployed into the eosio.token account, so there can't be new tokens created without 15/21 BP approval.

We are glad that EOS New York has called attention to this issue and as a BP eosDAC has always taken the security first approach and believes that we have solved this issue as a DAC.

So, here’s our take on this.

alt

Risk of Self-issuance Still Remains

First of all, eosDAC is in complete agreement with EOS Newyork's opinion on how malicious it can be to have a single owner key meaning a centralized authority taking full control over the tokens of the dApps and eosio.token system contract by design allows for a more dencetralized control over token contracts. The solution presented by EOS New York is great as it prevents a “bad” actor from modifying token balances as they please or adding sneaky actions, etc. However, there is still a risk of the token issuer being able to simply issue more tokens. It does not prevent the issuer with a single key to inflate the token (and sell them to crash the market, a.k.a., exit scam), which we consider as a great threat. Creating the token under eosio.token still allows the issuer to issue or burn the token. A lot of tokens need that feature for inflation (ie., IQ). How can we address this potential issue as well then?

Ability to modify token contract

Many projects do not use the standard token contract, in our case the EOSDAC token also stores whether a token holder is a member of the DAC.

DAC as a Solution

Well, naturally, we propose using a DAC as a solution. DACs don’t have the same problem because everything (funds included) is protected by more than one person. The more people, the less chance they would collude to do something malicious or make a mistake.

The eosdactokens account which has all the code for the EOSDAC token which you can review here. You can verify that the source code matches the code deployed on the chain (to see that we haven't added any extra functions): https://eospark.com/contract/eosdactokens?tab=security
As you can see, full control of this account is in the hands of dacauthority which is controlled by the 12 custodians since the DAC launched:

alt
alt

The main functionality for the DAC can be found in the daccustodian account with code you can review here. This includes functions like claiming pay, nominating custodians, casting votes, updating configurations, and more.

This means unlike the most tokens where a single person can do anything they like, we need approval of 10/12 Custodians (each carrying a vote weight of 1) to do any of above. For example, one of custodians may propose to take tokens from a particular account, but the other custodians would refuse to sign that proposal. Besides, a single owner key can always be lost or stolen, but if you have > 2 people, the chance is far lower.

Another thing is that the code update has to be broadcast to the network with an msig, so that anyone can verify that the code being deployed matches our github. We have to put the code change up for review in the eosio.msig contract and anyone can see that it is going to happen before the custodians sign it. Technically the custodians can compile the code from Github and check that the hash matches what was proposed on chain.

We also recommend watching this video (from 13:20) by EOS Weekly, as it does an excellent job explaining the DAC permissions system using easy to understand visuals as below:

How to try a DAC

It's easy and already available for the whole community. You can explore building your own DAC using a simple script we developed recently which automates much of the process for you. Try it yourself using the Github repo here

Here's a detailed video showing how the script works: