The DAO framework: a brief review of potential architecture breaches.

The DAO framework: a brief review of potential architecture breaches.

Decentralized Autonomous Organizations seem to be the wave of the future in collective funding and collective entrepreneurship. The DAO framework on the Ethereum platform is one of the latest developments in the architecture of this kind. Furthermore, a practical attempt to implement this framework - The DAO – went live recently, and the amount of funds it has already attracted seems surpassed only by the amount of online high-fiving around it. This will definitely be a very interesting case to research and observe. We became interested in analyzing theoretical possibilities of holes that can be exploited to obtain unfair results in this automated system. Here we would like to present a number of schemes that seem possible under this particular architecture.

By “holes” we mean peculiarities which, under certain conditions, would allow some participants to exercise bad will against others. Such a hole creates potential for situations when people need to rely on trust in an environment which aims to be trustless. Moreover, if such trust is abused an outcry for intervention by a law enforcer or regulator of some sort can become a realistic prospect. This would be a setback for a system that aims to eliminate middle-men or involvement of the state.

By “architecture” we mean not the program code of the solution, but the actual structure of transactions which the solution intends to implement. In this sense, architecture would be breached not by hacking the program code, but by finding ways to cheat other participants despite the underlying rules and procedures.

Before we present a list of potential schemes that formed as a result of our brief analysis, we would like to introduce some terms that will be used throughout this document:

DAO – a decentralized autonomous organization created on Ethereum or substantially similar blockchain platform, with architecture identical to The DAO (based on The DAO Framework).

Platform – a particular blockchain environment in which DAO is implemented.

Platform Currency – cryptocurrency native to that Platform.

Early Capital – Platform Currency obtained before market deployment of the Platform Currency (e.g., during development or premining), at its initial stages or otherwise at a price significantly lower than the one at the time of DAO creation. Early Capital is denominated in Platform Currency. However, its distinctive feature is that it was free or extremely cheap for its owner to obtain, which will not be the case for Platform Currency available on the market at the time when a particular scheme is happening. During infant stages of a Platform’s life the problem is not how to obtain Platform Currency, but rather how to infuse it with actual value.

Early Whale – anyone who was able to accumulate large amounts of Early Capital. Typically this would be someone with insider ties to the Platform, but not necessarily. It’s a case when market share of a whale is gained with the timing of an early bird.

Deciding Vote – a situation when a person, or a group of persons, is controlling sufficient DAO tokens to tip the scales in favor of a particular proposal (and also to ensure a quorum). An extreme case of this would be controlled majority – when these tokens by themselves are sufficient to ensure both the quorum and the desired voting outcome. However, any amount of tokens large enough to seriously affect the outcome can be instrumental for schemes against DAO architecture.

Contractor - a person or persons acting as a “contractor” in accordance with The DAO framework terminology. From technological point of view, this is the wallet originating a particular Project proposal. If this proposal is accepted by DAO, funds required under it are sent to this wallet. From organizational point of view these are persons (individual(s) or a legal entity controlled by individual(s)) offering their services to DAO in connection with investing its capital and managing these investments.

Project – business undertaking proposed to DAO and financed by it (a “contract” in accordance with The DAO framework terminology).

Shell Contract – a Project (and a respective contract) which is created as an integral part of an attack on DAO architecture, rather than as a viable business proposition to DAO. In essence, actual purposes of the Shell Contract are different from those declared in its proposal.

Subscriber – someone who has bought DAO tokens during its creation phase.

Investor – someone who bought DAO tokens after the Creation phase (e.g., on an exchange). The main distinction between them and Subscribers is that by the time Investors obtain DAO tokens they may cost much more than the amount of Platform Currency they represented at DAO creation phase (their nominal value). Thus, in certain cases Investors would take losses while Subscribers wouldn’t (or losses for them would be greater than for Subscribers).

Attacker – a person or group of persons attempting to exploit a hole in DAO architecture. We’re referring to the Attacker as “he” in this document, but, of course, this can also be a “she” or “they”. If the Attacker acts through a corporate entity of some sort, specific individual(s) are still behind the intent and benefit of the attack.

Target Holders – holders of DAO tokens other than the Attacker (essentially – both Subscribers and Investors).

We would also like to introduce definitions of two particular techniques, which do not generate any profit for the Attacker on their own, but can be a useful or essential part of a certain scheme:

Minority Wiggle – a situation when DAO token holders opposed to a certain decision that was accepted by DAO refrain from initiating a split. Such a situation is likely in cases when perceived risk of staying with DAO is smaller than perceived risk of splitting (e.g., missing out on profits from future Projects, as well as growing market price of DAO tokens). Such minority holders will find themselves forced to go in the direction in which the majority of DAO holders chose to go (hence, the “wiggle”).
The possibility of Minority Wiggle means, among other, that DAO split is not a panacea for protecting Target Holders against adverse decisions of DAO majority.
One Minority Wiggle” situation can be followed by another (or multiple others) as long as splitting from DAO keeps looking more risky than accepting the majority’s decision and staying. To further discourage splitting in case of attacks leveraging on Deciding Vote, the Attacker can manipulate Target Holders into an illusion that the majority is generally acting soundly and in good faith (e.g., by creating obviously adverse proposals and denying them).

Proxy Fragmentation – spreading of what is actually a single large conglomeration of Platform Currency and/or DAO tokens across multiple wallets controlled by the Attacker. This can create an illusion that a large number of unassociated decision makers is acting in a certain direction (voting on DAO proposals, subscribing to or subsequently investing in DAO tokens, paying DAO in connection with a certain Project), while in fact this is a coordinated action of the Attacker. Both spreading DAO tokens across multiple wallets and segmenting the voting process can be automated, so there are no particular limitations on the scale of Proxy Fragmentation.

Now to specific scenarios:

1. “Money grab”.

Not too elaborate in its core. However, there’s potential for extra bells and whistles.

1.A. How it happens:

i Shell Contract proposed by the Attacker gets accepted by DAO.
ii Funds are received by the Contractor/Attacker.
iii Once the Contractor/Attacker receives the funds, he uses them for his own purposes instead of duly spending them on the Project.

1.B. What it requires:

i An Attacker needs his Shell Contract to be accepted. In theory, this does not require Deciding Vote as long as the proposal looks attractive enough to secure a quorum and a positive voting outcome. Nevertheless, Deciding Vote would make this task easier.

ii It is also essential that Target Holders do not split from DAO after the Shell Contract is accepted - otherwise the attack will not bring any profits. So even controlled majority would not suffice for the attack to succeed (this is essentially what the split function of DAO architecture aims to tackle). This will be a psychological game, and both Proxy Fragmentation and Minority Wiggle can come into play here, alongside any publicity efforts to hype up the proposed Project.

iii The Shell Contract must require:
• a substantial amount of funds to be paid by DAO to Contractor up front (in the form of a deposit); and/or
• A payment schedule that allows the Contractor/Attacker to accumulate and retain a substantial amount of funds from DAO before things become too suspicious to Target Holders.

1.C. Unfair outcomes:

i The Attacker uses DAO architecture not to develop and commercialize a proposed Project which could generate profit for DAO, but to syphon out funds accumulated in DAO.
ii Target Holders will see the value of their stake depleted due to diversion of funds into the Project, while not getting a chance for returns on the investment they were expecting.
iii Once this misappropriation of funds is discovered by the broad market, Target Holders (Investors in particular) stand to absorb further damage due to likely depreciation of DAO tokens.
iv Any DAO holders that have split from DAO in connection with the Project in question (Investors in particular) may still see damages as the market price of tokens in the newly-formed DAO can decrease amidst the turmoil.

1.D. Additional comments:

While this scheme lacks conceptual sophistication, intricacies come into play when creating an appropriate façade for the operation. The main challenge for the Attacker is to lure a significant amount of Target Holders into investing in the Project and the existing history of investor fraud shows us that undertakings of this kind can be conducted with an amazing level of detail. There is also no shortage of proof that often seemingly reasonable people will be all too willing to believe in a lucrative opportunity to soundly evaluate risks looming behind it.
Sophistication in masking the scheme would also be required to mitigate subsequent issues with law enforcement, which presents another important challenge for the Attacker. This is, however, not impossible either. Money can be drawn out of the Project discretely (especially if it is done within the cryptocurrency domain), and it’s possible to create a convincing impression that the Project has failed for reasons beyond the Contractor’s control. It is also not necessary to just grab the money and disappear with it – for example, the Attacker could resort to the proven practice of embezzlement endeared by so many executives (overblown salaries/expenses, use of project funds for personal needs, covert financing of side businesses, etc). These things are not that easy to trace and prosecute as it is, and given unclear legal status of DAO and obscure reporting/audit arrangements this could be impossible to tackle under this given structure.
We would also like to remind that any need to rely on law enforcement already qualifies as an architectural hole for the purpose of this research (and, indeed, in the context of development of a decentralized governance environment).

2. “Business grab/asset grab”.

It’s not all about the money.

2.A. How it happens:

i A Project is accepted by DAO (not necessarily a Shell Project, as further explained below).
ii Funds are received by the Contractor and are used to develop the Project, creating valuable assets.
iii The Contractor-DAO relationship is terminated for whatever reasons (basically, the Contractor ceases serving as a contractor), and the former Contractor walks away while keeping control of these valuable assets.
iv Since the former Contractor possesses these key assets, he is in a unique position to complete the Project, while DAO is facing a choice of either going back to the drawing board or abandoning the Project altogether.

2.B. What it requires:

i General situation is similar to that in scheme 1 above (the Attacker manages to get a Project proposal accepted by DAO, while avoiding split by a significant number of Target Holders). Here, however, a Project must feature a viable underlying business idea (which, in turn, helps ensure that these previous conditions are met).
ii The Project must heavily rely upon certain key assets (intellectual property, production prototypes, brand recognition, etc) for its success. It is also very advantageous for the Contractor if information and expertise possessed by him are unique in the context of the Project (e.g., through key personnel, a network of partnerships or simply hands-on experience gained during the development process).
iii DAO should be unaware of existence of these key assets or is unable to claim them. For instance:
• The Contractor registers these assets in his own name.
• The Contractor withholds information on existence of these assets from DAO.
• The DAO is unable to prove (in legal domain) its rights to these assets because of unclear nature of DAO’s legal persona or its relationship with the Contractor. After all, the Contractor is a distinct private person or legal entity with a clear place in contemporary legal system. DAO, on the other hand, could face a number of hurdles while trying to protect, assert or register any rights within this system.

2.C. Unfair outcomes:

i The Attacker is essentially piggy-backing DAO, using its funds to create tangible and intangible assets vital for the Project, then taking the Project away from DAO and completing it to his own benefit.
ii Target Holders will see their capital depleted by payment of funds to the Project, while being essentially cut off from returns on this investment.
iii Target Holders (especially Investors) may absorb further damage as this unfolding of events negatively impacts DAO token pricing on the market.
iv Those DAO holders that have split into a new DAO in connection with the Project may see their respective tokens lose in price as well amidst the general turmoil.

2.D. Additional comments:

A peculiar feature of this scenario is that it’s not necessarily a pre-planned attack. Departure of the Contractor from the Project may be a result of actual disagreement on certain issues and not a premeditated extortion attempt. “Strategic business partners” today can turn into bitter enemies tomorrow, with each side totally convinced that the other side is the devil. For instance, if DAO fires the Contractor due to some disagreement (after all this hard work and all those sleepless nights), he may be compelled to feel justified in bypassing DAO and finishing the Project to his own benefit and to forget that none of this would be possible without DAO funding to begin with. Of course, whether it is a carefully conceived attack, or an emotional move, to a non-involved objective observer the economic outcome of this situation would still look the same.
The intentional Attacker could still use a Shell Contract. However, its shell nature would be not that there is no value in the Project (it must be there or the whole scheme makes no economic sense), but that it is structured in such a way as to facilitate expropriation by the Attacker of the Project’s key assets.

3. “Pump and dump”.

A classic trick for a new paradigm.

3.A. How it happens:

i The Attacker proposes a Shell Contract which is accepted by DAO.
ii The Attacker sends funds out of his Early Capital to DAO as if it was DAO’s share of profits generated by the Project. This creates an illusion of success of the Project behind the Shell Contract.
iii This boosts market confidence in DAO as a going concern and drives demand for DAO tokens (which begin circulating on exchanges after the creation phase is complete). The bandwagon/FOMO effect kicks in.
iv The Attacker sells off his DAO tokens to Investors at peak prices and bids everyone farewell.

3.B. What it requires:

i The Attacker needs to be an Early Whale.
ii The Shell Contract proposal must be attractive enough to be accepted by DAO and not scare Target Holders into a split. It helps that the Attacker can bombard DAO with consecutive proposals until one of them gets accepted – the trick here is in the ability to convincingly mimic success of a Project afterwards, specific nature of a Shell Contract is not that important.
iii Proxy Fragmentation will probably be used to make sure inflow of funds looks natural in the context of the Project.

3.C. Unfair outcomes:

i The Attacker attracts assets from outside the Platform and effectively exchanges his Early Capital (firstly converted into DAO tokens) against them without creating any actual value for Investors, who in turn purchase DAO tokens at a price that has no underlying economic justification.
ii At the conclusion of the scheme the price of DAO tokens plunges leaving Investors to absorb losses. The drop is likely to exceed the size of price inflation caused by the Attacker’s manipulations as the general confidence in DAO will be challenged. This may also adversely affect Subscribers.
iii Likely spill-over effect into the Platform Currency market may amplify losses for Investors and create additional losses for Subscribers (and bystanders holding the Platform Currency).

3.D. Additional comments:

A certain degree of prudence could be required on the part of the Attacker so that his injections into the market do not dampen the prices prematurely. This, however, can be managed and, in case the demand is inflated to a large enough degree, may not be much of a concern at all.
A perk of this scheme is that it will be virtually impossible for other market participants to know what (let alone who) exactly hit’em, unless the Attacker is completely careless.

4. “Indirect pump and dump” aka “The empty wheelbarrow”.

An extra twist for a classic trick (in a new paradigm).

4.A. How it happens:

i The Attacker uses his Early Capital to buy a large amount of DAO tokens, creating an impression of massive inflow of Subscribers.
ii This impression boosts public interest in DAO, prompting others to buy tokens while creation is still in progress.
iii Potential Subscribers need to obtain Platform Currency in order to convert it into DAO tokens. Demand for Platform Currency swells, and its price vis-à-vis other currencies (whether fiat or crypto) increases along with it. The hype spurred by the apparent inflow of funds into DAO creation is the actual driver of this price increase.
iv The Attacker sells off his Platform Currency during this period of peaking prices, essentially exchanging his Early Capital for funds attracted from outside the Platform.
v The Attacker can follow this up with selling off of his DAO tokens for further profits.

4.B. What it requires:

i The Attacker has to be an Early Whale.
ii The Attacker will probably need to resort to Proxy Fragmentation, otherwise it will be apparent that a large inflow of funds into DAO creation comes from a single source.

4.C. Unfair outcomes:

i The Attacker artificially inflates value of the Platform Currency. He then disposes of the Platform Currency with large profit. Basically, the Attacker receives value out of thin air – his Early Capital is worth nothing, unless he compels others to exchange it for resources extrinsic to the Platform.
ii Those who bought the Platform Currency during DAO creation (including other Subscribers) end up taking losses as the bubble driven by false expectations from DAO bursts.
iii Damage will be further aggravated by undermined market confidence, both in this particular DAO and in the Platform in general.

4.D. Additional comments:

While a large inflow of apparently dispersed capital at the creation phase can be a strong driver for prospective Subscribers by itself, the attack would likely prompt additional manipulations aimed at generating hype and further inflating expectations. For instance, the Attacker could also provide for a Shell Contract (or multiple Shell Contracts) to create an impression of upcoming proposals with strong investment prospects for DAO. Since such Shell Contracts have not been formally submitted to or accepted by DAO, no obligation on the part of the Attacker as the prospective Contractor would actually exist.
Just as with the previous scheme, everyone else will hardly know what happened or who exactly benefited. The twist here is that the Attacker uses secondary medium (Platform Currency rather than DAO tokens) for profiteering, which can further muddy up any understanding of events behind the price fluctuations.

5. “Pump and grab”.

Hybrid technology

5.A. How it’s done:

i This scheme is essentially a hybrid between scenario 3 and scenario 1.
ii The Attacker uses funds invested into his Shell Contract, supplemented by funds out of his Early Capital to mimic return on investment and some extra profit.
iii Establishing himself as a trustworthy Contractor in this manner the Attacker proposes another Shell Contract (for a Project requiring greater funding).
iv From this point on events unfold along the lines of scheme 1.
v Alternatively, this scheme can be implemented within a single Project that has payments to Contractor tied to milestones or some commercial performance metrics. The Attacker could use contract funds and/or his Early Capital to mimic successful performance of a certain metric (achievement of a certain milestone) and to unlock further (larger) funding and then grab the money. As Shell Contract would require less money up-front and more money once the Project shows some positive performance, Target Holders would be more likely to go for it in the first place.

5.B. What it requires:

i Conditions are generally the same as under scheme 1 (with certain nuances pertaining to the structure of the Shell Contract), however in addition:
• The Attacker needs to be an Early Wail, or
• Difference in funding size between the respective Projects (or milestones of a Project) has to be large enough to justify the Attacker’s expenses for initial simulation of profits.

5.C. Unfair outcomes:

i Same as under scheme 1;
ii It could be argued that damage to market confidence in DAO is potentially greater under this scheme, as fake nature of what was perceived as profits will be particularly discouraging.

Final points.

We’d like to stress that we make no assumptions or predictions on whether the risks we pin-point here will or will not come into existence with the current practical incarnation of this solution - The DAO (if they do, it’ll be quite spectacular though). In this paper we are focusing only on the underlying architecture, although me may look at how this translates to the particular case of The DAO later on. This is by no means an advice to invest in The DAO or refrain from such investment.

We do not warrant or represent that our analysis is exhaustive or error-free, and we welcome any constructive feedback on it (including any other potential scenarios of abuse, or any shortcomings in our analysis). We may revise and expand this document with time.

A discussion of how (and whether) the flaws we’ve described above could be tackled in subsequent versions of decentralized organization architecture is beyond the scope of this particular document, although it is of course an extremely fascinating one.

This document was mainly driven by curiosity. Still, there is another important consideration that prompts an informed discussion on the matter.

Decentralized collective action vehicles are a tremendous prospect – whether in a non-profit, or for-profit context. This instrument can be engineered with varying degree of diligence, and can be used both with good will and with bad will. Furthermore, the way in which it is implemented and used will affect the experimental decentralized environment in which it exists. Freedom from middle-men, including any regulators or other state bureaucrats, is the main advantage offered by decentralized solutions in general and DAO in particular. However, bureaucracy, or, at least, common-place toleration of it, did not arise out of vacuum. It is rooted in people’s fear of being mistreated and cheated by others. Any instance when fairness has been compromised serves as justification for people to submit a part of their rights to a third party (e.g., the state apparatus) in exchange for certain protections (whether real or implied). Any instance of fairness being compromised in the crypto-domain will likely result in a further push to regulate it.

The golden argument against involvement of any middlemen (including the state) in a decentralized system is the fact that such involvement is not necessary – participants are already protected by the very nature of the system which runs all of the transactions on a predetermined automated basis, in a “trustless”, “provably fair” environment. This argument will be undermined if “provably fair” turns out to be “probably fair”. Any potential for imposition of bad will on other participants in this system, let alone any cases of people actually willing and managing to take advantage of this potential, will weaken the position of those in favor of a truly deregulated and decentralized platform for human interaction.