Rangers Protocol Token Economy White Paper
ProtoclokenEconomyWhitePaperPaperJULY 2022 V. 2.0
TOKEN SYMBOL: RPG
CONTENT
Pt. 1 Rangers Protocol Introduction
Pt. 2 Token Design
2.1 Token Definition
2.2 Design Principles
2.3 Token Allocation
2.3.1 RPG Economic Circulation
2.3.2 RPG Usage Scenarios
2.3.3 RPG Acquisition Scenarios
2.3.4 RPG Appreciation Logic
2.4 Token Initial Issuance Mechanism
2.5 Supply Model
2.6 RPG Block Production Process and Incentive Mechanism
2.6.1 RPG Block Production Process and Rewards
2.7 Becoming a Proposal/Verification Node & Block Rewards
2.7.1 Proposal Nodes
2.7.2 Verification Nodes
Pt. 3 Ecosystem Construction
3.1 Foundation
3.2 Community Ecosystem
3.3 Proposal Nodes
3.4 Verification Nodes
3.5 Developers
Pt. 4 Governance Mechanism
4.1 Roles Involved in Governance
4.2 Distribution of Rights
4.3 Proposal Classification
4.4 Governance Process
4.5 Upgrade Mechanism
4.6 On-Chain Voting Upgrade Mechanism
4.7 Governance Parameters
4.6 Reward and Punishment Mechanism
4.7 Governance Fund
Pt. 5 Conclusion
Pt. 1 Rangers Protocol Introduction
Rangers Protocol is the backbone of a Web3 Engine for creating immersive Web3 applications. It provides comprehensive infrastructures for complex blockchain-application development, efficient Ethereum-compatible smart contract deployment, ultimate NFT cross-chain interoperability, and developer-friendly IDEs. Through building strategic partnerships in relevant industries, Rangers Protocol supports blockchain entrepreneurs to succeed in the Web3 world. Rangers Protocol minimizes the development difficulty for Web3 developers and maximizes the user experience of its Web3 applications.
From the technical point of view, Rangers Protocol is divided into two parts: Rangers Mainnet and Rangers Connector.
Rangers Mainnet is the core part of Rangers Protocol. It is a high-performance chain that supports complex applications and is highly scalable. It includes the RPoS-based VRF+BLS consensus mechanism, the EVM-compatible virtual machine REVM, the NFT protocol that can contain historical data of the entire NFT life cycle, the storage module responsible for asset and data storage, and the node module responsible for block generation.
Rangers Connector is responsible for completing the interconnection with various public chains, and its primary function is to provide cross-chain services for developers and users. It includes a consensus mechanism based on VRF+TSS, full nodes of the origin chain and target chain responsible for providing trusted data services, and modules responsible for cross-chain transactions.
Pt. 2 Token Design
2.1 Token Definition
RPG (Rangers Protocol Gas) is the Rangers Protocol ecosystem token, with a total supply of 21 million pieces.
RPG is the native token of Rangers Protocol. There are also RPG tokens issued on ERC20 and BEP20 format.
In the economic system of Rangers Protocol, ecological nodes that generate blocks are divided into proposal and verification nodes. This system adopts an open participation mechanism, allowing all users to participate in the system’s operation.
2.2 Design Principles
Technically, Rangers Protocol implements parallel computing through VRF random election + BLS signature algorithm and introduces high-concurrency collaboration and preprocessing technologies in distributed systems. It is better than Bitcoin in terms of decentralization – General network-compatible devices, rather than customized professional devices, can become nodes. In terms of security, VRF truly random numbers select groups to ensure that the working group is unique at a certain altitude. The periodic Check Point mechanism ensures that the block data is “final”. It eliminates problems such as long-range attacks and private mining.
In terms of design, the token economy system must create real value for each user and encourage users to increase their productivity. Therefore, Rangers Protocol designed the Protocol Principle and Transparency Principle. Protocol Principle: an excellent economic system relies on protocol behavior and economic incentives rather than lengthy procedures and coercive measures. Transparency Principle: the system can have a centralized design, but the black box should be eliminated as much as possible.
2.3 Token Allocation
2.3.1 RPG Economic Circulation
Tokens will circulate among users, developers, investors, and ecological nodes. First, Rangers Protocol will be connected to major platforms and encourage developers to develop, distribute, and operate their applications based on Rangers Protocol. Secondly, Rangers Protocol has designed the tokens purchase and stake mechanism, meaning developers need to purchase and stake tokens to use Rangers Protocol. When users experience applications deployed on Rangers Protocol, they also need to buy and consume tokens. For instance, they can pay tokens to application developers. With the ecosystem’s expansion, the token’s value will continue to increase. More and more token holders and more ecological nodes will make it a virtuous economic cycle.
2.3.2 RPG Usage Scenarios
RPG (Rangers Protocol Gas) generates blocks through ecological nodes divided into proposal and verification nodes. Ecological users pay RPG as a deposit and become a proposal node through community voting. Rangers Protocol has designed an RPG stake mechanism. Users need to purchase and stake RPGs to become a verification node.
The RPG Foundation will establish communities with different functions, including ecological governance, developer, and token holder communities. The community can use RPG to participate in the governance of Rangers Protocol.
Rangers Protocol will launch a sub-chain plan to support developers in releasing isomorphic sub-chains to Rangers Mainnet. Those sub-chains are allowed to issue tokens in the format of RAP20. The launch of the sub-chain requires the community to use RPG to vote.
Developers developing, distributing, and operating their applications based on Rangers Protocol need to consume RPG as the gas fee.
Users need to pay and consume RPG when using applications that have been deployed on Rangers Protocol, such as paying RPG to application developers. When users use Rangers Protocol for cross-chain or transfer, they also need to pay or consume RPG as usage or gas fees.
When creators use Rangers Protocol-based tools to publish and edit works and upload them to the blockchain when they carry out marketing activities in decentralized trading markets, auction markets, copyright centers, and other application markets, they also need to pay or consume RPG as usage or gas fees.
2.3.3 RPG Acquisition Scenarios
Both the proposal node candidates and the verification node candidates can receive RPG rewards by participating in the block production process.
Token holders delegate the tokens to nodes, indirectly participating in the network construction. Delegation can improve the network security, and the trustee can obtain certain rewards in the process.
The Foundation will regularly host development competitions, game contests and other activities to attract developers. Winning users or teams can receive RPGtoken rewards directly and their applications will be further incubated into commercial dApps by the Foundation.
The foundation encourages eco-applications to use RPG as a reward to users for their behaviors.
2.3.4 RPG Appreciation Logic
70% of RPG tokens are generated with block generation (proposal nodes and verification nodes) or unlocked with block generation (core team and incubator). 8% of the remaining amount is released every 180 days. The overall production is reduced every four years by 50% with a smooth production reduction curve.
The Random PoS mechanism adopted by the governance of $RPG tokens is the prerequisite for becoming a proposal node or verification node by staking a certain amount of $RPG. The more you stake, the higher the probability of being selected by the VRF mechanism to participate in the block production. The mechanism will reduce the instantaneous inflation rate of RPG and further ensure the slow release of $RPG tokens.
In addition to mentioned above rich $RPG usage scenarios (Infrastructure Scenarios, Stake Scenarios, Governance Scenarios, Sub-chain Scenarios) and the roles of participants (developers, users, and creators), Rangers Protocol seizes an exceptional blockchain game track with content and service as a business model. Basic application service components (IDE, Storage Service, Data Service, Private Key Management, and Assets Management) that can help developers reduce costs and improve efficiency have basic service components that have fee-charging scenarios and potentials comparable to the traditional game industry. These will increase the consumption of $RPG or help $RPG transfer to ecological co-builders.
2.4 Token Initial Issuance Mechanism
Investors (10%): Equal unlock (claim) each day. Token allocation for investors will be fully unlocked within 400 days.
The core team (14%): Core developers and maintainers, 8% of the remaining amount is released every 180 days
Incubators and consultants (7%): Incubators and strategic partners, 8% of the remaining amount is released every 180 days
Ecological community (49%): 8% of the remaining amount is released every 180 days, the ecological community consists of ecological nodes of both Rangers Mainnet and Rangers Connector
Rangers Mainnet Ecological Nodes (35%):
Proposal nodes (24.5%): join through RPG-staking election and provide special hardware
Verification nodes (10.5%): stake RPG, and provide required hardware
Rangers Connector Ecological Nodes (14%)
Ecological fund (20%): The unused amount is locked, community voting will be held, and relevant announcements made on the foundation website upon use
Market Operation (8%): DAO mechanism approves proposals based on community voting
Developers (7%): Grant mechanism distributes rewards to community members based on contribution
Market Value Management CEX (2%)
DEX Liquidity (1%)
KOL (0.83%)
Liquidity Rewards (0.67%)
IDO (0.5%)
Treasury (0%): Reward and penalty pool, dynamically balanced during operation, the value can be adjusted by community voting
Slash mechanism: Punishment based on the security threat level
Taxation mechanism: Service fees for middle layer protocols and upper-layer applications
2.5 Supply Model
2.6 RPG Block Production Process and Incentive Mechanism
2.6.1 RPG Block Production Process and Rewards
2.6.1.1 Block Production Process
Nodes that produce blocks will get corresponding rewards. The proposal node (proposal group) sends a proposal and hands it over to the verification node (verification group) for verification. After all individual verification nodes complete the signature verification, a group signature is formed. The block is allowed to be produced and broadcasted.
Average block production time: 1 block/second
Block-production node designation: Multiple nodes compete to form block nodes according to the established VRF random number.
Block generation mechanism: Each time a block is produced, the candidate nodes of the entire network randomly generate multiple proposal nodes through the VRF algorithm so that the proposers are random and unpredictable. The proposals are sent to the verification group in various channels in parallel, which limits the situations where the proposals and verifications misconduct.
The VRF mechanism selects the verification group based on the threshold signature algorithm, ensuring that the verification group is unpredictable, unselectable, and unconcealable. When the block is produced, it is only necessary to achieve a lightweight verification within the group. The block is produced quickly in a multi-channel parallel pipeline. Soft forks’ problem will not arise because the block generation rules directly specify a node to generate blocks. Even if another node completes the proposal simultaneously, it will not be selected as a block-generating node.
2.6.1.2 Within a Block Production Process
The proposal node is selected from the proposal group based on VRF and is responsible for generating blocks;
The proposal node selects the verification group through VRF, and sends the block to each member in the verification group;
Every member in the verification group will verify the block, sign, and send the signature to every other member in the verification group;
After verifying each group member, after collecting the signatures of a threshold number of others, the group signature is generated and broadcast to the entire network.
Block production speed: 1 block/second;
Group Lifecycle: 2 hours;
Block distribution cycle: 10 hours (36,000 blocks), once every 36,000 blocks;
Block rewards: A single block reward is calculated based on the current production mechanism;
Block distribution: Single block rewards are distributed according to distribution rules.
2.7 Becoming a Proposal/Verification Node & Block Rewards
*The following content refers to Rangers Mainnet nodes only.
2.7.1 Proposal Nodes
It requires staking of 2000 RPG to become qualified of being a proposal node. With Rangers Protocol’s development and the governance mechanism’s improvement, RPG’s number staked as proposal nodes continue to be adjusted. RPG cannot be unlocked during the period from the stake to block reward distribution. It can only be unlocked after the node reward is issued (10 hours). Each node can stake once in each block distribution cycle. When distributing RPG to the rewarded proposal nodes, it will be done according to each node’s RPG stake ratio.
After the block is generated, the proposal group will receive 24.5% of the total block rewards.
Each block-producing proposal node will get 7.35% of the total block rewards individually.
All nodes in the proposal group, including the block-generating ones, will share 17.15% of the remaining rewards according to the nodes’ stake ratio.
2.7.2 Verification Nodes
It requires a minimum staking of 400 RPG to become qualified as a verification node and later a candidate verification node. Rangers Mainnet sets no restriction on the verification node application; a qualified verification node can enter the random pool by staking and then waiting to be selected into a verification group. A candidate verification node (for short, candidate node) can be selected into multiple verification groups simultaneously. The maximum number of verification groups that a candidate node can join is calculated by its staking value divided by 400, rounded down. The more a candidate node stakes, the more verification groups it can join simultaneously.
Rangers Mainnet currently selects 5 to 10 members into a verification group. And the genesis group contains 20 members. The verification group members are randomly selected following the VRF consensus mechanism. Therefore, there exists the possibility of a candidate node not being selected into any verification group.
If the current number of awaiting candidate nodes is below 10, as long as they’re in an active-responding status, they would all be selected into the upcoming verification group.
If the current number of awaiting candidate nodes is above 10, the father group would randomly select 10 out of them.
The possibility for each candidate node to be selected into a verification group is the same regardless of the value staked.
The father group starts selecting the next verification group based on a certain block height without having to wait for the latest verification group to be dismissed. The selection for the next verification group will initiate as long as there are plenty of candidate nodes awaiting (a minimum of 5). Candidate nodes that weren’t selected into the latest verification group have the opportunity of joining the upcoming one.
A verification node can increase its staking at any time and for unlimited times without having to wait till the current distribution cycle concludes. During the period from staking to block reward distribution, RPG cannot be unlocked. It can only be unlocked after the node rewards are issued (10 hours). The RPG distribution for the rewarded verification node is based on its RPG stake ratio.
After the block is generated, the verification group will receive 10.5% of the total block reward. All nodes in the verification group will be rewarded according to the nodes’ stake ratio.
Pt. 3 Ecosystem Construction
3.1 Foundation
Rangers Protocol Foundation is mainly used for ecosystem construction, market promotion, healthy system operation, and community maintenance. Besides, some funds are used for investment to promote ecological development while maintaining the foundation’s long-term sustainable operation.
The foundation shall fulfill the following obligations:
Organize an open-source community or technology outsourcing team to complete Rangers Protocol’s launch and iterative upgrades.
Develop the market and build an application ecosystem.
Support or invest in Rangers Protocol-based dApp developers.
Prevent and punish behaviors unfavorable to the Rangers Protocol ecosystem and maintain the system’s healthy growth.
At the same time, the foundation enjoys the following rights:
Initiation of voting proposals.
Security deposits for forfeiture.
Rangers Protocol Foundation only has the right to initiate a proposal for the entire system’s governance. Then the community will vote to decide whether the proposal is finally implemented. In terms of community governance, the foundation can initiate and include without limitation the following proposals:
Modification of system parameters.
Proposal improvement and resource pricing usage.
Penalties for inaction or evil done by the proposal nodes.
Penalties for inaction or evil done by the verification nodes.
Punishment for evil done by dApp developers.
Other malicious acts.
3.2 Community Ecosystem
As a decentralized, game-focused solution, Rangers Protocol Foundation's development is inseparable from the community’s support. Rangers Protocol Foundation actively organizes and establishes communities with different functions, including ecological governance, developers, and token holder communities. Regardless of the community’s function, the goal of existence is to promote healthy and stable development.
3.3 Proposal Nodes
Ecosystem users pay tokens as a guarantee and become a proposal node through community voting.
As a proposal node, users must fulfill the following obligations:
Stake not less than the specified amount of security deposit.
The investment performance is good, and the server with a good network is used as the proposal node.
Guarantee long-term online activity.
During events, complete the tasks that need to be completed for node roles.
Correspondingly, the rights enjoyed by users include:
Income issued in the form of tokens
After the user is selected as a proposal node, the server performance and network performance must be guaranteed. Suppose the proposal node cannot be packaged to generate a witness unit within the specified time due to server or network reasons. In that case, it will be treated as a lost block and recorded in the proposal node’s statistical information, which will affect the reward distribution to the node.
3.4 Verification Nodes
Ecosystem users become candidate verification nodes by staking and are randomly selected as the contract’s verification nodes responsible for executing the contract when the contract is created or executed.
As a verification node, users need to fulfill the following obligations:
Hold a one-time stake on the verification node deposit.
Maintain a good network and stay online for a long time.
At the same time, the verification nodes enjoy the following rights:
Get income issued in the form of tokens
3.5 Developers
The foundation will regularly hold development or game contests and other activities to attract developers at the early stage. Winning users or teams can directly receive token rewards, and the foundation will further incubate applications into commercial ones.
Developers need to fulfill the following obligations:
Pay specific tokens as a deposit and submit application materials to become a certified dApp developer. Only certified dApp developer applications will appear in the protocol ecosystem application.
Smart contracts must not commit malicious acts; otherwise, they will be punished.
Pay a specific token to deploy the application.
Pt. 4 Governance Mechanism
4.1 Roles Involved in Governance
Governance Nodes
Proposal Nodes
Proposal nodes are generated using the algorithm mechanism of VRF+BLS. The user or organization uses Rangers Protocol to apply to the foundation for the proposal node election. After paying the deposit, they can participate in the election of the proposal node. The first batch of proposal nodes is generated through the foundation's directional invitation to the co-builders of the ecology. After the first round of the election, the expansion and re-election of proposal nodes will be carried out through community voting.
Verification Nodes
The token holder can freely join the Rangers Protocol verification network and become a verification node after running a node and pledging a certain amount of tokens.
Both proposal nodes and verification nodes can be the candidates for governance nodes. Other users can entrust their tokens to the governance node candidates. The system will rank the candidates according to their total equity (staking + delegation). The top 200 candidates will be elected as governance nodes.
Currency Holders: all token holders
Core Developers: core developers jointly building the Rangers Protocol infrastructure and community
4.2 Distribution of Rights
Governance Nodes
Initiate a proposal
Vote on the referendum proposal
Vote on the non-referendum proposal
Second the proposal
Token Holders
Initiate a proposal
Vote on the referendum proposal
Second the proposal
Core Developers
GitHub code control
Proposal Review
Proposal implementation
4.3 Proposal Classification
The decision-making right should rest with the “stakeholders,” which means the right belongs to the people. However, the implementation of the referendum needs to consider issues such as implementation costs, turnout rate, professionalism, and governance efficiency. This should not be the normal state of governance but the way of governance in the event of major differences. Therefore, Rangers Protocol’s governance adopts a combination of indirect democracy and direct democracy. Its core principle is: under normal conditions, governance nodes vote for governance, which is indirect democracy, while under major differences, the community is governed by public voting, which is direct democracy.
Referendum proposal
The referendum proposal occurs in a rather controversial scenario. Any currency holder can initiate a referendum proposal. The scenarios that require a referendum to produce results are as follows:
Amend basic rules
Make a major fork
Terminate the running chain
For example:
| Proposal Topic | Level of Importance |
|---|---|
Revise the verification group scope | Medium |
Add new proposal node | Medium |
Block height | High |
Lowest stake value | High |
Reward-distribution ratio for block generation | High |
Transaction fee | Medium |
Non-referendum proposal
Non-referendum proposals are ordinary proposals initiated by governance nodes and voted to produce results. Non-referendum proposals can be divided into the following types:
Text proposals: for decisions that need not be implemented
Software upgrade proposal: to initiate an upgrade vote on the chain to achieve a smooth upgrade
Parameter modification proposal: to modify manageable parameters such as system parameters
Account proposal: to freeze or unfreeze accounts (including contracts)
Incentive proposal: to allocate the balance in the governance fund account
Cancellation Proposal: to cancel the software upgrade proposal being voted on the blockchain
For example:
| Proposal Type | Proposal Topic | Level of Importance |
|---|---|---|
Parameter Revision | Revise the verification group lifecycle | Low |
Parameter Revision | Revise the verification group generation cycle | Low |
Parameter Revision | The number of candidate blocks for each block cycle | Medium |
Parameter Revision | Bn256, secpk256 curve parameter | Medium |
Parameter Revision | The distribution time for block reward | High |
Parameter Revision | The effective time for stake unlock | Medium |
Parameter Revision | Add new service command to the virtual machine | Medium |
Parameter Revision | The max gas amount /contract creation | Medium |
Parameter Revision | The max gas amount /contract transfer | Medium |
Parameter Revision | The max storage for contract codes | Medium |
System upgrade | Revise the gas fee of commands, e.g. Store | High |
System upgrade | Soft fork inspection cycle | High |
Parameter Revision | System upgrade | High |
4.4 Governance Process
Initiate Proposal
Currency holders can initiate referendum proposals, while governance nodes initiate non-referendum proposals. Each proposal should have a corresponding text description stored in the PIP repository on GitHub and managed by the core developer, similar to EIP. To prevent spam proposals, a proposal fee is required for every initiated proposal as its cost.
Screen Proposal
Referendum proposal: Since the referendum proposal is not the norm, multiple referendum proposals can simultaneously be initiated on the chain. These proposals will be sorted according to the highest margin. The proposal with the highest margin will be selected each month to enter the voting stage.
Non-referendum proposal: The successfully initiated proposal will directly enter the voting stage. Multiple proposals can be voted on at the same time.
Vote for Proposal
Referendum proposal:
The core of referendum proposal voting is equity voting, which lasts for two weeks. There are three voting options: support, object, and abstain. Only the tokens that are staked and delegated can vote. The voting adopts the "government node proxy voting + personal voting " model. The voting weight of the governance node is the sum of its own staked tokens and the number of entrusted tokens. If the delegator and the governance node hold different opinions, the delegator can vote on its own, and its voting weight is the number of delegates, and the voting options corresponding to this weight will be overwritten. During all voting processes, the tokens participating in the voting will be locked until the end of the voting. To alleviate the voting centralization problem caused by the majority of tokens being controlled by a small number of nodes, the number of governance nodes participating in voting should be large enough. If most governance nodes do not agree or do not participate in voting, the proposal will still not pass.
Non-referendum proposal:
The core of non-referendum proposal voting is governance node voting. As long as the node is elected as the governance node within the proposal's voting period, it can vote. The voting generally lasts two weeks. The proposal initiator can determine the voting period of the software upgrade proposal according to the situation. The voting adopts the one-governance-node-one-vote system. After the voting starts, the governance node's own staked tokens will be locked until the voting ends. Except for the software upgrade proposal, there are three voting options for other types of proposal voting, namely: "Yes," "No," and "Abstain."
There is no explicit option for the software upgrade proposal to simplify the voting process. Each governance node can indicate its voting position by upgrading its local node or not. For details, please refer to the upgrading mechanism.
Voting Results Calculation
Referendum proposal: There are three dimensions for calculating the results of referendum proposals:
i: Governance node support rate: the ratio of the number of governance nodes voting for support to the total number of governance nodes eligible to vote;
ii: Token support rate: the ratio of the number of tokens voting for support to the total number of tokens participating in the vote;
iii: Token participation rate: The ratio of the total number of tokens participating in the voting to the total number of staked tokens.
When all: Governance node support rate> P%, Token support rate> Q%, and Token participation rate> K%, the proposal is approved. Otherwise, the proposal is not approved.
2. Non-referendum proposal: There are two dimensions for calculating the results of referendum proposals
i: Governance node support rate: the ratio of the number of governance nodes voting for support to the total number of governance nodes eligible to vote;
ii: Governance node participation rate: the ratio of the number of voting governance nodes to the total number of governance nodes eligible to vote;
When both: Governance node support rate > M% and governance node participation rate> N%, the proposal is approved. Otherwise, the proposal is not approved.
The support and participation rates corresponding to different types of proposals are as follows:
| Type | Support Rate | Participation Rate |
|---|---|---|
Text Proposal | >50% | ≥66.7% |
Cancellation Proposal | >50% | ≥66.7% |
Parameter Proposal | >50% | ≥66.7% |
Upgrade Proposal | =100% | ≥66.7% |
4.5 Upgrade Mechanism
The upgrade mechanism guarantees that the network can continue to iterate and improve. For the different situations that may occur during the operation of the blockchain system, Rangers Protocol will provide targeted upgrade methods, mainly the following four kinds:
Optimizing upgrade: This type of upgrade is a functional optimization of the current chain version. Each node can decide to upgrade or not according to its actual situation without affecting the consensus.
Voting upgrade: This type of upgrade happens for adding new features or when the consensus mechanism is affected by patch repairing. This upgrade requires a software upgrade proposal to be initiated on the chain, and the voting results will determine whether to implement the upgrade or not. If the proposal passes, the node needs to complete a smooth upgrade without interruption of the network. The focus will be explained later.
Repairing upgrade: When a node cannot participate in the consensus as usual due to a low version or an abnormal transaction, the governance node can resume participating in the network consensus by installing a new version of the software.
Snapshot upgrade: When the blockchain system encounters a major abnormality that causes the entire chain to fail to produce blocks, as usual, a snapshot can be generated based on the precious normal network state. The network can then be restored based on the snapshot.
4.6 On-Chain Voting Upgrade Mechanism
Initiate Upgrade Proposal
Only governance nodes can initiate upgrade proposals, and a proposal fee higher than regular transactions needs to be paid when initiating. The following parameters need to be provided in the software upgrade proposal parameters:
The version number of the upgrade target.
The ID of the file the upgrade information of which GitHub describes, PIP-ID, must be unique.
The number of consensus rounds for voting on the upgrade proposal is N. This parameter will be used to calculate the voting cutoff block height, the designated voting cutoff block height for the Nth consensus round at the beginning of the current consensus round.
There can only be one software upgrade proposal in process on the chain. When there is already a software upgrade proposal or parameter proposal in voting on the chain, other software upgrade proposals cannot be initiated. In case of special reasons or emergencies, when it is necessary to initiate a new software upgrade proposal immediately, a cancellation proposal needs to be initiated to cancel the ongoing software upgrade proposal.
Cancellation proposal description: A cancellation proposal can be initiated only when an upgrade proposal is voted on the chain. The following parameters are required to cancel a proposed transaction:
To-be-canceled upgrade proposal transaction hash
The ID of the file that GitHub describes the upgrade information, PIP-ID, must be unique.
The number of consensus rounds for voting on the cancellation proposal. The voting cutoff block height calculated by this parameter cannot exceed the voting cutoff block height of the canceled upgrade proposal.
Proposal Voting Upgrade
After the software upgrade proposal is successfully initiated, it enters the voting stage. Only governance nodes can participate in voting. That is, node stake accounts can only initiate voting transactions. Before voting, local nodes need to be upgraded, and votes are counted on a one-node-one-vote basis.
The voting options of support, object, and abstain are not set in the voting transaction of the software upgrade proposal. Instead, they express their position through node behavior, as follows:
Supporters: After updating the local node version to the version in the proposal upgrade, vote on the upgrade proposal;
Neutral: You can choose to upgrade the node, but do not vote, and initiate a version declaration transaction to declare that the node has been upgraded so that you can participate in the consensus as usual regardless of whether the proposal is passed or not;
Opponents: There is no need to upgrade the local node or vote.
The following parameters need to be provided to upgrade proposal voting transactions:
Hash for initiating the proposal transaction;
The actual version number of the node. This version number needs to be the same as the version number of the upgrade destination in the voting to vote successfully;
Node signature. The signature is the signature of the node's private key to the version number of the node.
Although the node has been upgraded during the voting period, the logic currently running is still the logic of the old version. Switch to the new version of the logic after the implementation is complete.
Statistics of Voting Results for Upgrade Proposals
At the end of the voting block, the voting results on the upgrade proposal are counted. If the support rate of the proposal reaches 66.7%, the proposal is voted through and enters the implementation stage.
Proposal Implementation Upgrade
Due to the randomness of the governance nodes selected by VRF and to not affect the consensus, when we implement the upgrade, we need to ensure that the verification nodes in a particular consensus round are all upgraded nodes.
Therefore, when the voting deadline for the proposal is high, the support rate of the proposal reaches 66.7%. The upgrade will be implemented in the first block of the following consensus round, and nodes that have not been upgraded will no longer be selected to participate in the consensus. In the current settlement cycle, the eliminated unupgraded nodes will not be selected by the VRF to participate in the consensus. However, they still enjoy the stake income of the current settlement cycle.
Version Statement
Since there may be data incompatibility between different versions, the node version on the chain should be controlled to avoid consensus failure due to version issues. Therefore, Rangers Protocol has introduced a version statement. By initiating a version statement, the node indicates that its node version is consistent with the current chain version or the target version number in the software upgrade proposal voting. In such a way, it can participate in the consensus before and after the upgrade.
When the node and chain versions are inconsistent (the first two digits of the version numbers are different), the node will not be selected to participate in the consensus, even if its stake is high. At this point, the node can declare that its node is consistent with the chain version by initiating a version declaration transaction to participate in the consensus in the subsequent settlement cycle as usual. A version statement consistent with the upgraded version can be initiated when there is a voting software upgrade proposal on the chain. The version statement does not represent a vote. After the upgrade proposal is voted through, it is stated that the nodes with the same version number as the upgrade destination can participate in the consensus as usual even if they have not voted.
Quick Upgrade
Initiating an upgrade vote on the chain is a serious matter. In theory, there should be no possibility of revoking the proposal. All results should be left to the governance node for voting. But ours only allows one voting software upgrade proposal on the chain, so when an emergency needs to be quickly upgraded, if there is an unprocessed proposal on the chain, it will directly affect the processing speed of the emergency. Therefore, we introduce the cancellation proposal initiated by the governance node, and the voting cycle can be determined by itself. However, it must be within the voting cycle of the canceled proposal. By initiating a cancellation proposal and quick response of each node, the software upgrade proposal that is being voted on can be canceled in a short time so that the emergency plan can be quickly implemented. Only when there is a voting upgrade proposal on the chain, a cancellation proposal can be initiated. Once a cancellation proposal is commenced, it must be implemented, so we advocate using cancellation proposals only in emergencies.
The transaction to cancel the proposal requires the following parameters:
The canceled upgrade proposal transaction has;
The ID of the file describing the upgrade information on GitHub, that is, PIP-ID, must be unique;
The number of consensus rounds for canceling a proposal to vote. (The voting block height calculated by this parameter cannot exceed the voting block height of the canceled upgrade proposal)
4.7 Governance Parameters
Governance nodes can modify some system parameters by initiating parameter governance proposals. In order to avoid problems caused by the cross-implementation of parameter proposals and upgrade proposals, when there are voting upgrade proposals or parameter proposals on the chain, it is not allowed to initiate new parameter modification proposals. The voting period for a parameter proposal is two weeks.
4.8 Reward and Punishment Mechanism
The purpose of designing a punishment mechanism is to ensure that nodes and users are honest and trustworthy. Inaction or malicious behavior will be punished. Unlike the direct penalty mechanism of agreements such as Plasma, Rangers Protocol uses incentives in the economic model to encourage nodes to be honest and trustworthy.
Reward
Proposal rewards: Proposal rewards are automatically issued to the proposal initiating account after the proposal has been voted through.
Voting rewards: After the voting starts, the tokens participating in the proposal voting need to be locked until the voting ends. Therefore, voting rewards are proportional to the length of the voting lock-up time and will be distributed to each voting account at the end of the proposal voting.
Developer rewards: A proposal needs to be initiated on the chain, the voting results of which will determine whether to issue the rewards or not.
Loophole bounty: After confirming the existence of the loophole, a proposal needs to be initiated on the chain, whose voting results will determine whether to issue the bounty or not.
Punishment
The purpose of designing a punishment mechanism is to ensure that nodes and users are honest and trustworthy. Inaction or malicious behavior will be punished. Different from the direct penalty mechanism of agreements such as Plasma, Rangers Protocol uses incentives in the economic model to encourage nodes to be honest and trustworthy.
Suppose a user does not act for a long time or initiates a malicious attack while serving as a proposal node or verification node. In that case, the foundation can trigger the contract to freeze the user's stake, cancel the user's application for the role of the proposal/verification node, publicize it to the community, hold votings, and then forfeit a certain degree of fines towards the staked tokens. Similarly, certified developers must ensure the absence of malicious behavior in their developed applications or products. If they are found to be so, the foundation can also initiate penalties and confiscate developers' staked tokens. The confiscated staked tokens are transferred to the foundation to help the further construction of the community.
Proposal Nodes
In the financial model, we mentioned that the proposal node alone receives 10.5% of the total block reward. So if the proposal node does not act or do evil, it will lose this part of the reward, unwise for proposal nodes.
Verification Nodes
Assuming that the verification node does not act and the group verification fails, the proposal node will select another verification group. This will result in no benefit for all nodes in this group.
Governance Nodes
If a dishonest node achieves the upgrade by disguising its version, when the chain is successfully upgraded, and the governance node is selected to participate in the consensus, the block generation rate will be low because the consensus cannot recognize the generated block. The node will thus be punished by the system and even directly disqualified as a verification node.
4.9 Governance Fund
The governance fund comes from the foundation. Each year, a fixed proportion of funds is allocated from the foundation's account to the governance account. The balance of the governance account is allocated for incentives and salary distribution through proposal voting. When the proposal is voted through, it will be automatically issued through multi-signature.
Pt. 5 Conclusion
Ranger Protocol Token Economy and Governance Mechanism White Paper reflect our current thoughts on the token economy and governance mechanism. The token economy design itself is a virtuous economic cycle, enabling long-term currency holders to lock their positions and gain benefits. All users in the system will have corresponding benefits. Developers who hold tokens can obtain appropriate dApps development resources without worrying about user acquisition and infrastructure performance limitations and constraints. Users can also focus on the new experience of dapps and digital assets. And system maintainers also get their due rewards.
Besides, Rangers Protocol’s reasonable token design is based on a complete distribution mechanism, incentive income, and VRF’s truly random algorithm. RPG’s consumption, circular use, and inherent value provide a powerful growth engine for itself. It will be a qualitative leap to the underlying protocol of the existing blockchain industry.
Last updated
