This is the third and concluding entry in a sequence about utilizing the Ethereum Wallet to establish your own autonomous organizations. In the initial post, we elaborated on how to develop a token, followed by the subsequent post where we demonstrated how to forge a digital democracy governed by those tokens. Now, we will complete the loop and establish a token governed by the Organization!
We will adjust the token contract to permit it to be minted by your DAO. So, jot down your DAO’s current address in a notepad (be mindful of the icon) and retrieve this source code and you know the routine: contracts > deploy new contract > solidity source code > select contract
You can input the parameters however you wish (yes, emojis are allowed in string fields) but you’ll spot one new field that was previously absent: Central Minter. Here, add the address of your freshly created democracy contract.
Click Deploy and let’s wait for the transaction to be processed. After receiving at least two confirmations, navigate to your democracy contract, and you’ll find that it now possesses a million of your new coins. Now if you go to the Contracts tab, you’ll notice a new DAO dollar (admin page) contract in your collection.
Select the “mintToken” function on your right and then enter any address you possess as the “target,” along with the number of new mints you wish to create from thin air in that account. Press “execute” but don’t press send! You’ll see a warning indicating that the transaction cannot be executed. This occurs because only the Minter (which is currently set to the DAO address) can invoke that function, and you are trying to call it from your main account. However, the calling code remains the same, which is why you can merely copy it.
Instead, copy the contract execution code from the “data” field and keep it aside in a notepad. Additionally, obtain the address of your new “Mint” contract and store it safely.
Now return to the democracy contract and formulate a new proposal using these specifics:
- For the beneficiary, enter the address of your new token
- Leave etherAmount empty
- In the jobDescription, simply provide a brief description indicating you are minting new coins
- Under the transactionBytecode, paste the bytecode you saved from the data field in the previous step
In a few moments, you should see the details of the proposal. Unlike other fields, transactionBytecode can be exceptionally long and thus costly to store on the blockchain. Therefore, instead of archiving it, the individual executing the call later will provide the bytecode.
However, this does create a security vulnerability: how can a proposal be voted on without the actual code present? And what stops a user from executing different code once the proposal receives votes? That’s why we maintain the hash of the bytecode. Scroll down a bit in the “read from contract” function list, and you’ll find a proposal checker function, where anyone can insert all the function parameters and verify if they correspond to the one being voted on. This also ensures that proposals are not executed unless the hash of the bytecode precisely matches the one in the provided code.
It’s an older code, but it checks out
Now anyone can participate in voting on the proposal, and once the voting duration has concluded, anyone with the correct bytecode can request the votes to be counted and the contract executed. If the proposal garners sufficient backing, the newly minted coins should appear in Alice’s account as though it were a transfer from address Zero.
Why a transfer from address zero? Because performing the reverse, sending a coin to 0x00, is a method to effectively annihilate it, but more importantly, because it is stated in the contract code. You are free to modify that as you prefer.
And now you possess a central minter contract that solely exists within the blockchain, entirely fraud-proof since all of their transactions are recorded transparently. The mint can also withdraw coins from circulation by simply directing the coins it holds to address Zero or by freezing the funds in any account, but it’s mathematically impossible for the Mint to perform any of these actions or to create more coins without the backing ofenough stakeholders of the mint.
Potential applications of this DAO:
- The establishment of a universal stable cryptocurrency. By regulating the overall quantity of coins in circulation, the Mint stakeholders can endeavor to create an asset whose value remains relatively stable.
- Issuance of backed asset certificates: the coins may symbolize an external currency or items that the Mint possesses and can validate to its stakeholders and token holders. When the Mint acquires or disposes of more of these assets, it can burn or produce additional assets to ensure that their digital inventory consistently aligns with their real counterparts.
- Digitally supported assets. The Mint can retain ether or other Ethereum-based digital currencies and utilize that to support the value of the circulating currencies.
Suggestions for Enhancements
There are several approaches through which this framework can be further optimized, but we will leave it as a challenge and exercise for the reader:
- At present, votes are cast by stakeholders based on freely tradable tokens. Could membership instead be determined by invitation, where each member holds a single vote (or perhaps utilize quadratic voting or liquid democracy)?
- What alternative voting systems could be implemented? Perhaps the vote could be more nuanced rather than simply binary: you could choose to delay the decision, or cast a neutral vote that still contributes to the quorum.
- Currently, all proposals have an equal debate duration. Could this be made proportional to the value transfer being proposed? How would you translate that into tokens?
- Is it feasible to design a superior token that can be autonomously generated by sending ether into it, which can subsequently be retrieved by burning the token, with a fluctuating market price?
- What additional assets or capabilities can the DAO possess beyond tokens?
