-
Notifications
You must be signed in to change notification settings - Fork 3
Gravity Economic Logic
- To create, maintain and evolve an open Smart Contracts platform based on Gravity.
- Strong privacy assurances.
- Resilient and interoperable.
- With a modular architecture.
- Building on top of and expanding the web platform.
- Allowing novel consensus, persistence backends.
- Allowing novel and specialized language front-ends.
- Allowing a vibrant ecosystem of applications.
- As a Publicly accessible, owned and controlled Common. (e.g. bitcoin)
- Accessible to everyone.
- Governed by all stakeholders on the platform.
- Making sure it stays true to its vision.
- Where stakeholders participate as a free choice, out of the alignment of their individual and collective best interest.
- That relies as little as possible on synchronous, central decision making mechanisms.
- Favors collective emergent decision making over central body decision making.
- As automated as possible.
- With high quality of code
- High performing
- Highly efficient
- Reliable
- Tested
- While making it sustainable, and lucrative for developers to work full time on it.
- Permissionless
- Low barrier to entry (Participation / Collaboration).
- Incentivizing early adopters and contributors while promoting usage amount subsequent adopters and contributors.
- Rewarding contributions. Creating a liquid, exchangeable on demand token designed to slowly but gradually appreciate.
- That does not require negotiation as a mechanism to valuate a contribution
- That works across jurisdictions. (e.g. bitcoin)
The Gravity token serves as a form of liquid equity where the tokens issued forms a reward commensurate to the contributions to the project. Following the principle that the whole is larger than the sum of its parts, these rewards track the “cost” of the contribution at that moment in time, understanding that such cost should be less than the value added to the project.
Any individual or organization that brings in material contributions to the project in the form of:
- Architecture / Design documents.
- Source Code
- New user stories
- New modules
- Bug Fixes
- Documentation
- Testing
- Security Audits
Developers earn Gravity tokens for their contributions. New contributions, represent new issuance of tokens. Contribution rewarding is done according to the Gravity token issuance.
Any individual or organization that operates the physical infrastructure required for Gravity to operate, including but not limited to:
- Computer hardware
- Networking
- Security
- Management
- Maintenance
Operators offer computing services, in exchange for Gravity tokens. Together with the developers output (The software), the Operators (The hardware) create the Gravity token backing.
Any individual or organization that desires to launch and run an Gravity application on the platform. Users buy/trade Gravity tokens to run their contracts.
Gravity Tokens are issued whenever a contribution is added to the project. A contribution is deemed to be a part of the Gravity Codebase and other Digital Assets such as documents. Contributions are partitioned as User Stories. The token value of each User Story follow the User Story Valuation logic. Only contributions that do not break any of the project tests will be accepted.
There are three kind of contributions:
Core contributions must be accepted by the lead developer committee, for inclusion on the Gravity project. They are related to fundamental elements of the architecture, that can’t be isolated as modules. They include but are not limited to, core components, documentation, APIs, interfaces, etc.
Module Contributions are those that can be isolated, as complete units and provide very specific functionality. Examples of modules, are language front-ends, consensus algorithms and persistence backends.
Application contributions are those that are built utilizing the Gravity platform, but are fundamental to the operation of the network/platform as a whole. These include:
- The Gravity Contract (Gravity Assembly)
- The Gravity Distributed Exchange
- The Trading Agent
- The Gravity Court
- The Gravity Library
- The Gravity Market
The Gravity token is exchangeable for smart contracts execution power made available through the network of Operators. Each Operator will set a rate in Gravity tokens, depending on the value of the Gravity Token on the open market.
The second form of backing is functional. The Gravity token must be used as a “proof of stake”, associated to each operator. This will allow a user to decide the level of trust they’ll put onto an Operator, to run their smart contract, depending on the costs associated with byzantine behavior. Operators holding onto the most tokens would be deemed the most trustworthy, because they would be the ones that could lose the most if they were detected engaging in byzantine behavior (Facilitated by a determination of the Gravity Court when a “dispute” arises). This creates a second additional but natural demand source for the token.
There is a possibility of “burning” tokens, that a hosts has put forth as a guarantee of non-byzantine behavior, whenever this hosts is proven to have engaged in such behavior (Detected through the Gravity courts or a commonly agreed upon arbitrator).
Following the principle of having the least amount of “manual” decision making, and attempting to automatize most decisions in well defined processes, the following decisions are subject to a dual voting counting mechanism.
- The maximum number of developers on the lead developer committee (top X)
- The cost of the contribution value metric / hour, per units of account
- The quorum required to reach a decision.
- The change, through a functional proposal, of the following:
- The contract execution pricing logic.
- The User Story valuation logic and rewarding algorithm.
- The unit of execution definition.
- The decision making mechanism (Governance) itself.
- The change of any of the other parts of the Gravity contract.
The decision making through vote is calculated by counting the votes in the following way:
- 50% of the decision making power is made through one developer from Lead developer committee, one vote.
- The 50% remaining, is made through one token, one vote.
The lead developer committee will be composed of the top “X” most prolific developers, by the accrual of the total historic value of each contribution, regardless of the value of the tokens allocated to them as a result. The number of the top most prolific developers can be updated through voting based decision making (See governance).
The token value of each user stories, will depend on the collective valuation of a number of different metrics for the contribution like:
- Code fitness of purpose
- Coding efficiency
- Clarity
- Test completeness
- Bugs present
- Complete Documentation
This means, that every Gravity developer has the opportunity to (anonymously) rate the metrics above. In addition, each user story, will record the aggregate number of hours utilized to deliver the feature described. To do so, tasks such as initial implementation, design phase and documentation, bug fixes, etc. will be accounted. This will result in a time to value created ratio, that will provide a metric for the effectiveness of the User story implementation. In this way, also every contribution towards the User Story, can be tracked with this metric. Finally, associated to each User story task, will be the a record of the value of the Gravity token (Denominated in mua’s), which will be utilized to retrospectively reward the contribution tasks.
The valuation of a contribution however, is retrospective too. In time, as developers asynchronously and collectively rate the value and quality of a contribution, a more accurate and commensurate reward will emerge. As the contribution value adjusts, so the amount of tokens issued to the developer(s). This means that any contribution may continue to generate tokens in time.
The average of all the Developer’s contributed tasks, will be the Developer’s metric of effectiveness. This metric, is also utilized to calculate the preliminary reward amount, to be issued and credited to the Developer account at the moment the contribution is accepted.
Prior to Gravity launch, token allocation will occur manually following the same logic above. This means allocation will be proportional to the amount of value and effort contributed to the project. The total number of tokens allocated will depend on the initial token pricing.
The initial token pricing (in mua’s) will be determined collectively by defining a fair global development hourly market rate.
The pricing to execute a contract must follow the following goals:
- It does not encourage wasteful/inefficient code (to artificially require more computing power)
- Moreover, to incentivize the creation of high performing, highly efficient infrastructure.
- It covers the cost of development more than fairly, while encouraging early participation and engagement.
- It encourages operators to hold on their tokens as a form of investment. (Like most “miners” would)
- It encourages operators, and makes it profitable to continually expand operating infrastructure.
- Encourages early adopters to build as many applications and uses on top of this infrastructure, to maximize its utilization.
- It assures the long term maintenance and evolution of the platform.
To fulfill what is outlined above, the contract pricing can’t be entirely connected with the cost of execution. The cost of execution, should be set by the operator, allowing for free competition and market based pricing. The cost of execution may be calculated with the metrics provided by the platform.