DAO Token Holder Update

This is an update for the DAO Token Holders wondering how they may be affected by the hard fork and what they can do to help themselves and the ecosystem. The latest news:

The Software Clients

The Devs are hard at work! The Go team, the C++ team, Ethcore (Parity, the Rust client), and even Vitalik himself (Python) are all actively developing, reviewing, and testing the hard fork Client upgrades.

If you can code in those languages and have any interest in learning more about Ethereum you can help the Ethereum protocol by diving into the github links above to look over the code. We have dedicated our entire team to this, and any help in this effort is greatly appreciated.

Each client is going to need to hard code the balance transfer of each of the attackDAOs that was able to receive ETH without burning DAO tokens. This requires a forensic analysis of the blockchain to confirm that there are no other hidden attackDAOs out there.

If you want to help in any way with this investigation or any other blockchain analysis related to The DAO, please contact @griff on The DAO’s Slack to be connected to the relevant people working on these projects.

Narrowing Down the Options

There seems to be a general consensus that the innocent childDAOs will not be included in the hard fork specification due to the complexity their integration would bring (potentially introducing bugs into the code) and timing requirements (the hard fork would need to occur on July 16th). Only the black hat and white hat attackDAOs will have their funds moved to the withdraw contract. This coincides with option 1b in Christoph’s last post.

There is also a very strong consensus around implementing only one hard fork that provides a complete solution as soon as possible. This is option 3c in Christoph’s last post.

There are, however, still discussions being held about what to do with the extraBalance and the other excess funds that can not be claimed directly by token holders at a rate of 1 ETH per 100 DAO tokens.

The consensus default option is 2b in Christoph’s last post. This gives each DAO Token Holder the ability to solve this problem in a decentralized fashion, by donating their fair share of this extra amount to anyone they please; see the solidity code for the withdraw contract. There are several organizations being formed that might step up to receive these donations in order to send them to the people they feel were not made whole by this hard fork. These groups are being referred to as “edge cases” for simplicity’s sake.

One such organization is contemplating taking on the responsibility of solving this issue completely on their own in a slightly centralized fashion. This would be option 2c in Christoph’s last post. If that happens it would be fantastic, but it is not at all guaranteed to be an option.

There are many disincentives for individuals to take on this responsibility. It would involve a lot of volunteer work by trusted individuals who are naturally quite busy. Additionally there are many potential risks as this is all a very grey legal area. However, if a diverse, trustworthy group creates a well-tested multisig, they can then use that multisig to manage other smart contracts that can fairly distribute the funds to the different “edge cases.” This solution is being explored and if it succeeds, it will utilize this withdraw contract.

If you like to review solidity code, please dive into Github to comment and analyze the code of these smart contracts.

If you might consider yourself an “edge case” please contact @griff on The DAO’s Slack.

Potential Steps forward

If you are a DAO Token Holder

If a hard fork does take place, the code that is being written would allow you to call 2 functions to retrieve 1 ETH for every 100 DAO tokens. This is assuming the hard fork happens, and as I can not predict the future, it’s impossible to tell what options may or may not be available to the token holders. You are responsible for managing your own risk.

If you are a childDAO Token Holder

All DAO token holders that have called `splitDAO()` (not merely voting for a split but also taking the extra step to call that function) and burned their DAO tokens to receive childDAO tokens have found themselves in a prickly situation.

All childDAOs are an exact copy of The DAO and therefore open to the same exploit. The good news is that this exploit can only be performed 7 days after a new Curator proposal has been created by calling `splitDAO()`.

So as an honest individual, your best strategy is to first whitelist a wallet address that you know can send ETH (always backup your private key files AND passwords), then create a proposal to send yourself your fair share of the ETH that is in your childDAO. You might be safe as long as no one ever creates a new Curator proposal in your childDAO.

Please join The DAO’s Slack and coordinate with other childDAO token holders in the #child_dao_community channel. We have dedicated resources to monitor this channel closely and will answer any questions that may arise (assuming someone else doesn’t beat us to it).

If you are in a childDAO that split before the attack, you can use this wiki post to create a proposal with the appropriate parameters:

Recipient: Your whitelisted account address

Amount: Your fair portion of your childDAO’s ETH x10¹⁸ (to make it in wei)
Description: This is the best way to communicate with other childDAO token holders, use it!
transactionData: Leave BLANK
debatingPeriod: 1209600

newCurator: Leave the box empty.

Send Ether: 0 (for childDAOs there is no Proposal Deposit required)

If you are in a childDAO that split during or after the attack, please contact @griff on The DAO’s Slack.

To Be Continued…

This is an update on a rapidly developing situation. The contents of this post reflect the situation at the time of its writing and could quite quickly become out of date. Expect more to come.