Self-sustainable Governance by blockchain structure proposal CMCO model

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
CMCO = Core, Marketing, Contracting model

I proposed in the announcement thread that everyone with an idea for how the Self-sustainable Governance by Blockchain proposal Evan posted today, April 22, 2015 (mark that day, it'll be a world holiday soon!) should work, make a thread and have people help hash it out until the OP consolidates all the ideas that needed to be addressed into the first post This will act as one of the proposals. We would then review all the proposals, which will be well hashed out, but different, so we can see them all taken to their logical conclusions, and express the strengths and weaknesses of each proposal. And finally choose which one we want. This is what I just came up with, so please, hash away at it in detail! No perceived fault should be withheld, including desired projects and where they should sit in the scheme.

CMCO:

The first thing that would be a given, but details expressly worked out, would be the core team's obligations and the number of developers and other workers needed to perform these duties. The Masternode Network would be required to approve this budget. This would give the general budget for the core development team:

Core development:
1. fix loop holes and attack vectors
2. create a plugin interface to make side chains possible
3. find a way to truncate the blockchain to trim dead end, emptied accounts older than _ years. or however it might be done.
4. maintain the core wallets from highly controllable to easy to use mobile wallets. You can't keep others from making wallets, but we should have an official wallet for all needs.
5. Estimate cost of projects proposed by the community and review bids (because they are the most trusted and knowledgeable people we have)

The same thing would be done for marketing

Marketing:
1. Maintain a presence at all conventions
2. Have a traveling speaking team which makes presentations at colleges, corporate invitations, TV and magazines etc...
3. Have a budget for a new advertisement video once??? every quarter??? get to point where they can be put on TV, etc...
4. The marketing team would employ these people and organizers

And finally, the community could come up with the projects they would like to see built. Such as projects that would enhance the platform: These would be chosen by the community, arraigned in order of importance, then voted on. Those that are pre-approved are sent out to bid. Then finally with a budget and time constraints, these projects would be chosen based on need and cost and amount of time required to see results.

1. A trustless, decentralized exchange run on the masternode system.
2. A TOR-like network that can provide better privacy and higher traffic loads to it's customers
3. Other value added services

The core team would be tasked with reviewing the bids to see if they are reasonable, and award the bids.

The above projects could take some of the income of those projects and distribute them as 1. payments to masternode servers that opt in (and have to maintain a high level server), payments to maintain the code, solve issues and 3. a portion of the income could also be set asside where it could be used to fund sub projects.

I can see that at some point, the big projects that we need will only require a bit of maintenance and future projects should be funded off those branches. For reasons of scalability more than anything else. We simply can't expect Masternode owners to vote on an endless number of projects. The essential projects of under 20 in number could work, but after that, they have to grow out of these branches with new voting infrastructure. The project maintenance should be covered by their income, and those developers could use the funds they get from the project to start something new, without masternode permission as long as they can fund it themselves, or with other projects. ETC...

Those projects that are essential but can't be expected to earn funds would have their maintenance covered by the network.

Finally, the dedicated funds for development would start as a "tax" of 15% of block rewards, to get things started, but then slowly reduce the "tax" or whatever you want to call it, to the point where only enough funds are taxed for maintaining the core of the infrastructure and everything else is not the responsibility of the main network.

Issues:

It's possible, when trying to predict future costs, that the % of donation isn't enough to fund ongoing needs.

if too much funding is provided, it might create an incentive to spend and be wasteful.

Needs some sort of checks and balances
 
Last edited by a moderator:
  • Like
Reactions: bhkien

stan.distortion

Well-known Member
Oct 30, 2014
928
547
163
Can I take a step back and suggest a means of handling the proposals as the starting point? I've not really been following closely so maybe its already been covered, I can see how the network can handle the funds involved but not how it can handle the other components, proposal, approval, discussion, modifications etc. I can kind of picture how all that could be handled by proposal objects, maybe even something similar to namecoin with various fields but there's likely many more ways it could be done. Maybe I'm back to front with that and we're right in looking at the things we want to achieve before defining the means of communicating them, idk :/