CROSSVALUE Chain Governance Overview

The governance of CROSSVALUE Chain has a predetermined process for changing protocols. It is important to note here that this process is not relevant to how people or applications use the protocol.

Once mainnet has been released, CROSSVALUE Chain is open for participation of on-chain activities. During development, there were no restrictions on incorporating escrow functions utilizing Escrow nodes or sending transactions. Anyone can build applications on the CROSSVALUE Chain.

There is a process to propose changes to the CROSSVALUE Chain core protocol, which is the foundation for these applications to operate.The process should be done carefully, as any change to the core protocols could affect any behavior of CROSSVALUE Chain. In order to ensure that changes are made safely and supported by the entire ecosystem, exceptionally high hurdles are set for the change process.

Comparison of On- and Off-chain governance

1. On-chain governance

On-chain governance means that proposed protocol changes are determined by votes of stakeholders who are the holders of governance tokens, and the voting takes place on the blockchain.

2. Off-chain governance

Off-chain governance means that decisions on protocol changes are made in an informal process of discussion and, if approved, implemented in code.

The change of the CROSSVALUE Chain core protocol employs the off-chain governance described in (2). It is carefully implemented through a defined process from proposal to decision.

However, while the CROSSVALUE Chain governance is off-chain at the protocol layer, applications built on CROSSVALUE Chain may use on-chain governance for each. And in the future, if on-chain governance is passed by the CKP, it is possible that the XCR could be used as a governance token to move to on-chain governance.

Stakeholders

The CROSSVALUE Chain community has a variety of stakeholders, each with their own role in the governance process. Listed in order from the stakeholder remotest from the protocol are:

・XCR owner: An owner of XCR

・Application user: A user who uses applications on the CROSSVALUE Chain

・Voting node: A voting node participating in the consensus of the CROSSVALUE Chain. Voting nodes are randomly selected for each transaction

・Application/tool developers: Developers of decentralized applications running on the CROSSVALUE Chain (Defi, NFT marketplace, etc.) or tools such as wallets and systems interacting with the network

・Escrow Node: A node which is randomly selected based on the volume of transactions and receives transaction confirmations from a randomly selected Voting node to determine the authenticity of transactions

・DACS Node: A node providing storage for the CROSSVALUE Chain

・CROSSVALUE Kaizen Proposal (CKP) Drafter: Proposes changes to the protocol in the form of a CROSSVALUE Kaizen Proposal (CKP)

・Protocol Developers (a.k.a. "Core Developers"): Protocol Developers performing various implementations on the CROSSVALUE Chain

What is a CROSSVALUE Kaizen Proposal (CKP)

One of the key processes used in the governance of CROSSVALUE Chain is the CKP. This process does not eliminate the possibility of moving to on-chain governance in the future, but initially it is a process for making suggestions to the protocol developers; the CKP is a standard that defines new features and processes for the CROSSVALUE Chain and can be created by anyone in the community.

Official Process

The official process for making changes to the CROSSVALUE Chain protocol is as follows:

Improvement Proposal: To formally propose a change to the CROSSVALUE Chain, it must first be detailed in the Core CKP. If accepted, it becomes an official specification of the CKP to be implemented by the protocol developer.

Presentation of a CKP to the protocol developer: After a CKP is created, it is presented to the protocol developers for discussion. Discussions may already be taking place in parallel in the CROSSTECH Discord.

Possible outcomes at this stage include the following:

・The CKP will be considered for future network upgrades

・Request for technical changes will be made

・Rejected if low priority or if the improvement effect is not impactful compared to the development effort

Iterate on the final proposal: After receiving feedback from stakeholders and the community, changes will probably need to be made from the initial proposal to improve security or to meet various needs.

Once the CKP reflects all changes deemed necessary, it will be presented again to protocol developers. They may then proceed to the next step, or new concerns may arise and the proposal may be iterated again.

Included in the Network Upgrade: If the CKP is approved, tested, and implemented, it will be included as part of the network upgrade. Since a network upgrade requires the entire network to be upgraded at the same time, the CKP is typically combined with the timing of the upgrade.

Network Upgrade Activation: Once the network upgrade is activated, the CKP will go live on the CROSSVALUE Chain network. Note: Network upgrades are typically performed on the test net before being activated on the mainnet.

This flow is very simplified, but outlines the key steps to enable protocol changes on the CROSSVALUE Chain. Informal elements of this process categorized in detail:

Informal Process

・Understanding of past work

CKP drafters must have a good understanding of past work and proposals so that they can seriously consider deploying them in the CROSSVALUE Chain mainnet before preparing a CKP. This will allow them to bring in new proposals that have not been rejected in the past. To find out about past CKPs, please check the main CKP repository, CROSSVALUE Chain Forum.

・Working group

The first CKP drafts are rarely implemented on the CROSSVALUE Chain mainnet without edits and changes. Typically, CKP drafters work with a subset of protocol developers to hammer out, implement, test, iterate, and finalize proposals. In the case of Ethereum, these working groups required months (sometimes even years) of work. Similarly, CKP drafters making such modifications need to engage relevant application/tool developers early on to gather end-users’ feedback and mitigate deployment risks.

・Community consensus

While some CKPs are simple technical improvements with minimal differences, some are more complex with inherent trade-offs, affecting different stakeholders in different ways. Therefore, some CKPs may be controversial within the community.

At the moment, there is no clear manual on how to handle contentious proposals. Protocol developers do not have the means to force people to upgrade their networks and will usually avoid implementing proposals that would outweigh the interests of the community as a whole.

CKP drafters are expected to seek feedback from all relevant stakeholders. If you are the CKP drafter in a contentious CKP, you will need to address objections in order to gain consensus on your proposal. Given the size and diversity of the Ethereum community, there is no single metric (such as coin voting) that can be used to measure community consensus, and CKP drafters must be flexible in dealing with the status of their proposals.

In addition to the security of the CROSSVALUE Chain network, the protocol developers emphasize the value of application/tool developers and users. This is due to the perspective application/tool developers and users on CROSSVALUE Chain make the ecosystem more attractive to other stakeholders. Furthermore, the CKP needs to be implemented for all clients managed by different teams. Therefore, as part of this process, it is important to convince and gain buy-in from protocol developers and community members of the valuable protocol changes which will help end users while solving security issues.

Currently, CROSSVALUE Chain will adopt a policy of not intervening in the event of a bug in a contract or loss of funds in order to maintain the trusted neutrality of the system.

*The CKP process began