Xenea Governance Overview

The governance of Xenea 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, Xenea 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 Xenea.

There is a process to propose changes to the Xenea 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 Xenea. 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 Xenea 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 Xenea governance is off-chain at the protocol layer, applications built on Xenea 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 XENE could be used as a governance token to move to on-chain governance.

Stakeholders

The Xenea 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:

・XENE owner: An owner of XENE

・Application user: A user who uses applications on the Xenea

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

・Application/tool developers: Developers of decentralized applications running on the Xenea (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 Xenea

・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 Xenea

What is a CROSSVALUE Kaizen Proposal (CKP)

One of the key processes used in the governance of Xenea 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 Xenea and can be created by anyone in the community.

Official Process

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

Improvement Proposal: To formally propose a change to the Xenea, 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 Xenea 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 Xenea. 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 Xenea 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, Xenea Forum.

・Working group

The first CKP drafts are rarely implemented on the Xenea 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 Xenea 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 Xenea 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, Xenea 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