ICO is now closed!
I'm Dexaran from Ethereum Classic community. This ICO is my personal attempt to raise funds to realize my ideas for developing Ethereum Classic. I've been a volunteer developer since the Ethereum Classic project began. I disagree with the current vision for the development of ETC, and in my opinion it is moving in the wrong direction.
I believe that the current situation is a result of an inefficient distribution of human resources, In my opinion two separate development groups work on the same things for two separate but nearly identical projects.
I'm afraid that this will lead to ETC being considered a deprecated project as soon as Ethereum carries out the next valuable network upgrade and ETC can not keep up.
Ethereum Commonwealth will work on for-profit projects as well. DEX token shareholders would participate in revenue distribution. You can find a full list of Ethereum Commonwealth projects here. For-profit projects are marked with "revenue" label.
Ethereum Classic Naming Service (ECNS) is a modified version of ENS for Ethereum Classic. It is already finalized and deployed on ETC chain. ECNS will be added to MyEtherWallet and ClassicEtherWallet soon.
Initial capital: no initial capital required
Revenue: 0.5% commission from registered nodes, 50% commission from invalidated names
Classic Smart Pool is a decentralized smart-contract based mining pool. Mining centralization is a great problem of most POW cryptocurrencies. More than 80% of mining power in Ethereum emanates from 5 mining pools. The mining pool, managed by a smart contract, effectively solves this problem for Ethereum Classic!
Initial capital: initial capital is required to compensate bad luck miners at launch stages of the Classic Smart Pool
Revenue: 0.5% pool commission
Infura is a service that sells the Ethereum API. It will be reasonable to build such service for Ethereum Classic.
Initial capital: initial capital is required to buy domain names, rent servers, launch nodes and pay a web-designer for the UI development
Revenue: payments from bought API endpoints
Smart-contract based exchange for tokens.
Initial capital: payment for a web designer for the UI development
Revenue: 0,5% exchange comission
Naming service for smart-contracts with automated ABI and address loading by human-friendly contract name. More user-friendly than ENS or ECNS. Already working on ETC main net. Temporary UI can be found here.
Initial capital: no initial capital required
Revenue: comission from registering contract names
ETC has the “moral high ground” ETH has the highest amount of progress with development. I think that the main difference here between the two chains is ideology. I have stated this position earlier.
I don't agree with the Ethereum Foundation on TheDAO hardfork, but I don't want to blame them, I just think differently than they do. It is not necessary to discard the compatibility of the core clients just because of principles and personal ambitions. ETC did not differ from ETH because of the underlying technology. ETC only differed due to ideology.
Compilers, virtual machines and programming languages.
In the last few months, I have worked with many developers of the Ethereum Foundation on solving a number of problems that are related to both chains. ETH and ETC use the same virtual machine, the same programming languages and the same compiler. As a result of this we have the same problems and developers from both chains can help each other to solve them.
I have already demonstrated this with my ERC223 which solves many of the problems associated with unnecessary monetary loss on Ethereum and saves Ethereum Classic from this problem as well. For those of you that do not know. ERC223 token standard helps prevent losses with the sending and receiving of tokens on both the Ethereum and Ethereum Classic network.
I have also discovered errors in the solidity compiler.
I also feel it is important to review the coding standard since experience shows that it is very hard to design a fault-tolerant smart-contract system. I prefer to rely on time-tested GNU coding standard.
There are a number of problems that are same for both projects, and I'm concerned about the fact that none of the ETC developers, apart from me, are involved with solving these problems.
I think that it will be much more effective to cooperate with ETH instead of competing with it. This will allow all 3d party services to integrate with both chains easier and developers to participate in development of both projects. Ideally, I'm going to start a team that can participate in the development of both ETH and ETC. It will be twice as effective to have two teams competent enough to work on both projects.
This does not mean that I want to just "copy & paste" all ETH updates. For example, I would like to support many of the suggested updates from the Ethereum Classic community for system governance and monetary policy.
I'm against breaking compatibility with the technical aspects of Ethereum while it is not necessary. Such as an upgrade of the virtual machine. I do not think that that the virtual machine has anything to do with our differences in ideology and it is absolutely irrational to establish a separate team to develop and maintain a new virtual machine that will do many of the same things.
We have lots of common problems that we can solve together! Let's help each other to grow and develop. With more people involved in each project, the higher quality of work that we can come to expect.
1. Restore compatibility of GETH and GETH Classic.
This will allow easier adoption of third-party services such as MetaMask and Mist. It will also allow easier adoption of future main upgrades such as Raiden, Swarm, pre-compiled contracts and Metropolis updates.
2. PR Campaign.
I believe that one of the most important things is the atmosphere in the community. Having investigated DASH, PIVX, and DECRED, I’ve come to the conclusion that it would be good to hold games, contests, art bounties and other social-oriented events. I believe it would be a good idea to spend portion of the funing for small monthly bounties.
3. Coding standard.
This is one of the important things for contract developers. I believe we should review the coding standard that is currently described in Ethereum Dociments and update them to improve contracts’ code readability. I think that we should base a new coding standard on time-tested GNU coding standard. Being a smart-contract auditor I can say that readability of code is extremely important for developing error-free contracts.
4. Maintain developed projects.
I'm aiming to finalize ECNS, ERC223 and DexNS. I need to hire a web-site developer to improve DexNS web interface, write a patch fo MyEtherWallet to support ECNS and maintain ERC223 if it will be needed.
5. Token exchange.
I want to finalize a Decentralized Token Exchange which is already in development.
6. Protocol upgrades.
We should prepare a code base for future protocol upgrades. I think that it will be a good idea to cooperate with Ethereum Foundation developers that are currently working on Raiden and SWARM.
I believe that one of important points is to have zk-SNARKs enabled on ETC. I'm ready to work on implementation of custom zk-SNARKs (requires VM upgrade) or implement pre-compiled contracts.
8. Governance system.
I'm aiming to work in the named direction during the year. After the year will pass we will establish a smart-contract based voting, where DEX tokens would be used.
On 1st September 2018 I will deploy a voting contract. Everyone can file an issue on github repo of DEX token. We will link github's issues with a smart contract to allow DEX owners to vote on the proposed goals. We will focus on developing top voted proposals.
Our reality shows that even one single developer can perform quite a complicated job. It's just a matter of time.
I'm aiming to hire at least two full-time developers to team up with me and work on protocol upgrades. I'd like to hire a web-site developer and an employee who will engage in socio-oriented work as well.
I do not have the means to do it right now, so I'm now working on completing my current projects. I will decide if I can afford it or not after the end of the ICO.
The success of the team depends on how much funds would be contributed during the ICO.