The Ethereum community has largely voted in favor of a hardfork solution to undo the DAO theft and return the funds to the token holders. According to latest estimates, 86% (2714965.14 ETH) are in favor of the fork, while 459187.23 ETH have voted against.

In a blog post, Christoph Jentzsch outlines three decisions that are to be made:

1. Is the ether collected from all DAOs (mainDAO, attackDAOs and all childDAOs) or only from the attackDAOs and the mainDAO.
    
2. What should happen to the ether in the extraBalance.
    
3. Whether or not to delay the more detailed parts of the withdraw mechanism by putting all the ether into a multisig then solve it through a second hard fork later.

In response to the various options in the hard fork put forward by Jentzsch, Vitalik Buterin has that recommended developers to focus their efforts on the option ‘1b/2b/3c’ – implying ignoring the innocent childDAO’s ether (1b), allowing token holders to donate their share of the extraBalance to ‘something’ (2b), and solve everything now, without any delay (3c).

Jack du Rose, co-founder of two Ethereum projects (Colony and Ownage ab (Colony and Ownage) explains that unlike Bitcoin, an Ethereum hard fork will not involve a wholesale rollback of the blockchain state. It will involve only a surgical strike to convert theDAO to a withdrawal only contract, allowing theDAO tokens to be redeemed for Ether. It will not affect any other transaction history or balances.

CryptoCoinsNews noted that the implementation of the hardfork code needs to be activated by July 21, as after this deadline, the situation will become more complicated.

“The consensus logic of the hard fork isn’t too complicated, but networking aspects very much are, which as of now no other client really cared about. Geth has both fast sync and introducing light sync which requires a lot more effort on the networking part to make sure the network partitions cleanly between forkers and non-forkers”, Péter Szilágyi, Software Developer at Ethereum Foundation and one of the main developers of the hardfork code, told CCN. “The soft-fork almost blew the network up because we rushed it and didn’t consider all aspects, I don’t want to make that mistake again. We’re evolving the code slowly, properly covering all possible issues we can imagine with various tests, among other end-to-end network simulations.”