THE MOVEMENT - SOCIAL CHANGE ENGINE
A fully decentralized organization, self-funded and built from the ground up by community members dedicated to global and social change. All are welcome.
SOCIAL ACCOUNTABILITY GOVERNANCE
Version 1 - April 2018
The text was updated successfully, but these errors were encountered:
Once the Sphere get approved by the vote of the token holders, the MVT deposited are moved in a general Fund/Wallet of the Movement which can be used to fund internal projects/works/contest or anything generally useful.
If the Sphere does not get approved the MVT are returned.
I think you made a great point here about a spam filter. Ensuring legitimacy of proposals will definitely be important in the future. A financial obligation would prevent a majority of the spam proposals.
-Submitting a Sphere Initiative locks the funds proposed in the Offering.
-Funds will remain locked for the duration of the community review and community vote.
-After the community review period, the creating sphere has a period of 12 hrs. to commit their proposal to a community vote.
-Committing an Initiative to vote is a check that the creating sphere is involved and serious about their proposal.
-Not committing proposal to vote will deposit funds into a community fund.
-Upon the outcome of the vote, the locked funds will then be deposited into either a generated development wallet within the machine or, returned to the creating sphere.
The Sphere Initiative Format in the offering section would have to be changed to 1 MVT to Infinity in section 4.
I do think that a time limit should be started as to when this 1 MVT minimum should be reviewed. In the future, if the market cap was to reach 100 million USD, that would mean 1 MVT is equal to around 33 USD. That price grows exponentially as the market cap increases. My fear is that eventually, the cost of submission will be too high for some. Ease of access to the platform should be a priority.
I could understand the concern of a 12-hour window thinking about the what if's. So what if say a 1-person sphere is building a proposal. This person does the work to fill the proposal format. I think that coupled with the locked funds of the Offering are more than enough to deter forgetfulness because there's real passion behind it. And strictly speaking, as a matter of fact, I do understand that natural disasters happen, but I think in a circumstance like that, their proposal would be the least of their worries.
And to protect the rest of the what if's, proposals to recover funds can be submitted. The community will vote on the legitimacy of this sphere's claim. A favorable vote will refund to initial funds from the community fund.
Now with a decentralized organization like The Movement, a future sphere could be larger. Many people working together located all over the world. During that 12 hours, any person within that sphere has the ability to commit the proposal to vote. The odds of a multi-person sphere all missing the 12-hour window slim to none.
-It's really cool, I really love it!
Sphere Initiative Name: Title of the Initiative. Must represent the Initiative as a whole.
Mission Statement: A detailed and executable plan to achieve the desired outcome.
Required Resources: Exact specified resources needed to complete Initiative.
Offering: Bounty Program - Ranging from 0 MVT to Infinity
Voting Length: Initiative specific voting timeframe. Ranging from 24 hrs. to 7 days.
-Just asking myself if giving the ability to offer more than the total supply is a good thing security wise...
Specifying voting length is cool so poll won't get indefinitely stuck waiting for voters!
DarkTrollCoin, you bring up a good point and I should attempt clarify. My thoughts on using the word Infinity were probably incorrect. Being that there is only 3,000,000 MVT in existence and that the funds in the proposed offering would be locked once submitted doesn't allow for "infinity" MVT. So really, if the funds aren't available at the time of proposal, the proposal wont be accepted. An oversite on my part. Thanks for pointing that out.
I'm in on this; where do we start? I think we should start with a simple basic universal MVT solidity contract in which other component contracts could inherit as a cornerstone. We'll need to "define" some sort of ownership , preferably "consensus driven" to delegate responsibility. I guess I could play around with the idea and throw some code together for peer review. All good? Note: I am not a coder, but I know enough to rough something out.
@cjmoles I think you're on the right path. Feel free to experiment!
What I'm envisioning is a percentage of participation bounty program that will be split into 4 sections with a bounty manager or team that will keep track and report progress to the community as well as help facilitate the needs of project's development. My hope is that this will allow bounty participants to shape all aspects of the development through their collaboration to meet the needs of the community.
Tentatively, the plan is roughly as follows unless there are objections from the community. Also, if there are suggestions or ideas from anyone please share.
I've set aside 25,000 MVT that will be transferred to 5 addresses. These 5 addresses will coincide with the initial 5 parts of the bounty. Additional sections can be added if the need arises.
We also might want to think about identifying a decentralized communications platform for development discussion.
I think something like this will be a good start. Thoughts?