Upgrading DAO contract, what to do about old tokens

[abruptdismissal]

Let’s assume that at some point in our great DAO experiment we are going to want to upgrade the contract. A discussion of how this works can be found in the DAO whitepaper released by slock.it (https://download.slock.it/public/DAO/WhitePaper.pdf) under section 9. “UPDATES”

Essentially the procedure is as follows:

1. A proposal is submitted to call the newContract() function of the DAO itself, with the address of the new contract (new_addr)

2. This proposal is voted on (needs 53% quorum), and passes

3. executeProposal() is called

4. newContract(new_addr) is called with the address of the new contract from the proposal

5. All reward tokens that have not been previously assigned to child DAOs (through splitting) are moved in the old DAO internal map to new_addr. This means that any payments that are sent to the old address will continue to be split amongst any child DAOS as per usual, with the remainder being sent to new_addr

6. Any DAO tokens held by the old DAO itself are moved in the internal map to new_addr

7. All ethereum funds held by the old DAO are transferred to new_addr

From there it can be assumed all new proposals, voting etc happens on the new contract.

This leaves us with a problem, namely what to do about the old tokens, which are all still held by their original owners (excluding any tokens that were held by the old DAO itself, and transferred to the control of the new contract).

The paper mentions two possible solutions:

1. All tokens remain at the old address. Trading proceeds as normal, and any time tokens are used in the new contact (for voting etc), they must reference the old token balance. For actions that require the new DAO to access tokens, such as burning tokens for splitting, the user must first call approve() on the old contract, to give permission to the new DAO. There is an additional issue, with how to handle blocking tokens for voting. Generally tokens are prevented from being shifted around after being used for voting until the vote closes, to prevent double voting. I assume voting would also require pre-approving the DAO to shift tokens into a blocked state, to be released after voting closes.

2. New “DAOv2” tokens are issued on a 1-1 basis with the old tokens. The exact mechanism could require a user burning old tokens, or the new DAO could (how?) simply recreate the old distribution. Burning the old tokens by transferring them to the new DAO has the advantage that old tokens can continue to be traded and remain valuable (as they can be traded in for DAOv2 tokens at any time)

Both these solutions strike me as inelegant. In my view, the problem could be solved in future contracts by having a seperate token sub-contract that just handles the tokens, and that is “owned” by the DAO contract. The owner of the sub-contract can then execute specific “owner only” functions necessary for burning tokens for splitting and blocking tokens for voting. Ownership of this sub-contract could then be transferred upon a successful call to newContract().