The cheqd Governance Framework embodies the following General Governance principles. These General Principles SHOULD be used as checks and balances against new Proposals on the Network.

Updates, amendments or revisions to this Principles list can be made through the process explained in the Section Major Network Changes.

1. Interoperability

cheqd SHOULD enable digital identity data for an entity to be represented, exchanged, secured, protected, and verified in an interoperable way, across multiple decentralised identity Networks, using open, public, and royalty-free Standards, such as the Standards for Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) defined by the World Wide Web Consortium (W3C).

2. Accessibility

cheqd SHOULD enable applications to build on top of the Network, maximising usability and accessibility, in order to create additional value and utility for other members of the industry.

cheqd can be defined as a Layer 1 component of the Trust over IP stack, and SHOULD act as a module for other Layers in the stack to plug-into, from a technical and governance perspective.

3. Transparency

cheqd Network and Community SHOULD enable Network Users to easily access and verify information necessary to understand the incentives, rules, policies, and algorithms under which Node Operators and other participants of the Network operate.

cheqd SHOULD therefore, open source its work to the entire community.

4. Integrity

cheqd Network and Treasury SHOULD uphold the highest levels of integrity in the running of the Network, ensuring decisions and proposals are made in a public domain, without coercion, in the collective best interests of the cheqd Community.

5. Control

Network Users SHOULD control their own identifiers and encryption keys, and be able to employ end-to-end encryption for all interactions.

Network Participants SHOULD always have a right to vote on the cheqd Network and have full control of their choice of vote.

6. Security

cheqd Network code and updates SHALL provide appropriate, measurable security of the data, including protection against unauthorized or unlawful processing, accidental loss, destruction, or damage, using significant technical and organizational measures.

cheqd Network SHOULD make publicly available their network health monitoring, data and analytics tooling.

7. Data Protection

cheqd Network Users SHALL NOT enable personal data, as defined in the GDPR, to be written to the Network, in either a plain text proposal, memo, DID Document or a software update.

cheqd Network SHALL ensure any data uploaded to the Network is anonymous and uncorrelateable.

A User’s right to be forgotten (i.e. the right for their personally identifiable information to be erased or put beyond use) SHALL be promptly honored wherever applicable.

8. Notification

Network Users SHOULD notify the other Users of the Network as soon as practically possible if there is a security breach, data breach or else if a Regulator has made an inquiry into the Network’s operations.

9. Decentralization

cheqd SHALL NOT require reliance on a centralized system to represent, control, or manage the Network’s governance. Instead, the decisions on the Network should be made by a diverse collective, in line with the Principle of Increasing Entropy, ensuring there is no single point of failure.

10. Sustainability

cheqd SHOULD always strive to be environmentally sustainable, given the imminent threat of climate change and the important role that technology can play in mitigating this threat.

For example, this MAY be achieved through a Carbon Tax on the Network. A Carbon Tax is a nominally small fee that is charged for the use of the Network, which can be put aside into a Community Pool, and donated for the betterment of the environment.

11. Inclusion

cheqd Users SHALL NOT exclude or discriminate against any other User within its governance scope, on the basis of age, body size, visible or invisible disability, incapacity, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, country of origin, heritage, personal appearance, race, caste, color, religion, or sexual identity and orientation.

cheqd Users SHOULD always seek to use inclusive and neutral language to best reflect the interests of a diverse, multidisciplinary and multicultural Network.

12. Privacy

The cheqd Network SHALL NOT allow any use of the Network that results in technical or regulatory privacy infraction, such as surveillance, personal tracking, and abuse.

cheqd Network SHOULD use the tools available to it, such as the veto power to ensure that the network is not used as a Layer 1 for Layer 2 and 3 applications that compromises Privacy.

Introduction

Governance Frameworks are generally perceived as largely inaccessible documents, for various reasons:

1. People do not understand what governance is, or why it is important;

2. The documentation is generally convoluted and difficult to find;

3. They are too formal and written in abrasive, legal language;

4. They do not educate the reader about the concepts they are governing.

At cheqd, we want our Governance Framework to be something that is easy to read, understand and use in practice. We want this document to be clearly understood by a diverse and multidisciplinary audience and collective, spanning across the world.

We are committed to writing our documentation in simple language, using easy examples to explain difficult concepts, and designing a Governance Framework which is open and easy to change.

This is the most important part of any Governance Framework...

Core to our Governance Framework, above all, is first, common understanding and common acknowledgement of how a system is run, and secondly, clear, accessible and democratic ways to influence decisions and the direction of change. This can only be achieved through clear communication, transparency and inclusivity.

Let's make this easy, accessible and inclusive

Through this Governance Framework, WE want to help YOU as a Network User, Node Operator or cheqd Community Member understand and familiarise yourselves with the following:

1. What Governance (and decentralised governance) is;

2. What cheqd’s mission is, and how our Network functions;

3. How you can impact Network Governance, either in off-chain forums, or through on-chain Proposals;

4. How the cheqd Network rewards participants through transaction fees and rewards;

5. What Principles YOU SHOULD uphold while using the cheqd Network;

6. How cheqd has built its Network to become more decentralised over time, as Low Entropy tends towards High Entropy.

In return, we kindly ask that YOU, while using the cheqd Network:

1. Demonstrate empathy and kindness toward other people;

2. Act with openness and respect to Users of differing opinions, viewpoints, and experiences;

3. Give and gracefully accept constructive feedback;

4. Accept responsibility for your mistakes, and are open to apologizing to those affected by our mistakes;

5. Focus on what is best not just for YOU and your desired outcomes on the Network, but make decisions with the entire cheqd community in mind.

We also ask that YOU follow the provisions of our Code of Conduct to ensure the best experience for others in the community.

Let’s make cheqd a success together, and payment rails for trusted digital data a global standard: improving trust and efficiency in every industry.

This section is a set of Foundational Principles which are core to the Network. They set a baseline of Principles which the General Principles sit underneath in terms of hierarchy.

The Foundational Principles SHOULD NOT need to change throughout the lifecycle of the Network. They are designed to be flexible enough to underpin the Network as it progresses.

Updates, amendments or revisions to this Principles list can be made through the process explained in the Section .

1. The Principle Principle

A Principles based Governance model is toothless unless there is a Principle explaining how to properly follow and interpret the Principles.

Given the genesis structure of the Network, a lot of power to govern the Network is vested in the architecture, and decentralised consensus from the Users of the Network.

For this reason, the Principle Principle holds that Network Users should follow these Principles.

This Principle SHOULD be upheld in the following way:

If there is a clear contradiction between a Principle listed in this Governance Framework and a Proposal made to the Network, that Proposal SHOULD be either:

1. Rejected, meaning that it will not reach voting stage, but the creator of the Proposal will be refunded its tokens;

2. Vetoed, meaning that it will not reach the voting stage and the deposited tokens for the Proposal are burnt.

Naturally, it will be at the discretion of the voter whether to reject or veto the Proposal. The User SHOULD use their reasonable judgement to make this decision, based on the degree of harm the hypothetical Proposal could do to the Network.

Throughout this Governance Framework, it will be made clear where the veto should be used, to maintain the security and safety of Network Users.

2. The Balancing Principle

With respect to the Principle Principle, it is also crucial to balance the right to freedom of expression with the other Principles set forth in this document.

We do not want Users to feel hesitant to make genuine, well-intentioned Proposals, for fear of having their Proposal vetoed. We want Users to feel that their voice can be heard without being shut down and penalised. And we want to instill a culture of inclusivity and open-discussion.

The Balancing Principle adds on to the Principle Principle. If there is a Proposal to amend, add or remove a Principle which is well-reasoned and well-intentioned, such Proposal SHOULD NOT be vetoed.

Voters SHOULD make a judgement call, based on their own morals and perceptions whether such a Proposal is genuinely well-intentioned; or whether it is created to antagonise, discriminate or cause harm to a set of persons or Users.

Of course, if there is a strong personal sense that a Proposal constitutes the latter, then a veto vote will be the best course of action.

We cannot set or regulate these boundaries, and we will not be able to intervene here, but we want the Network to govern this delicate grey area itself, minimising toxicity and maximising inclusion.

We want the Network to keep itself in-check.

What does this look like?

3. The Principle of Increasing Entropy

Entropy is the transition from a centralised Network, where very few people make decisions that change the course and direction of the Network, to a fully decentralised Network, where a large, diverse collective reach consensus on the course and direction of the Network.

At the genesis of the Network, there will be a set of default parameters and decisions made by a select few. Therefore, this state has very Low Entropy because there is purposefully curated form, structure and order.

As more node operators join the Network, as more decisions are made, and as the capability to make a decision on the Network is spread across more and more Users, Entropy increases. This is because the initial structure, form and order is gradually dissipated.

This Principle therefore holds that decisions made on the Network SHOULD be taken with a view to increase Entropy and to make the system more decentralised.

This Principle SHOULD be self-fulfilling in the sense that any Network Proposals made after genesis will most likely increase Entropy.

There will likely become a point where Entropy has reached the point of sufficient decentralisation and that its increase may plateau slightly for technological reasons. The Network SHOULD maintain this high Entropy state.

Governance is not an easy concept to understand. This is because it is something which cannot be easily visualised and lacks a common definition.

If I said to you, what is an apple? You might respond by saying that it is a small round fruit which is commonly red, but can be green or even yellow. If I asked 10 people the same question, I would get a pretty similar answer. Apples are easy, they exist in the physical world and we come across them on a daily basis.

Now, if I asked the same 10 people: what is governance? Someone might say governance is about how the country is run. Someone else might say that governance is about law and order. None of them will provide a correct or incorrect answer, they will provide an answer based on what their conception of governance is.

Governance can come in many shapes and sizes. You can govern something as large as a country, or something smaller such as a school, or something intangible like a social media platform… or a blockchain.

What is Governance?

Governance is a challenging concept. It relates to setting rules and standards that people abide by and follow. Most models of governance rely on a hierarchical structure, where a sovereign authority regulates from a top-down perspective. For example, a national government is responsible for setting laws and enforcing them on the public. This makes sense because, without a level of prescribed governance to keep the public in check, order would descend into anarchy.

At cheqd, we like to think about Governance as constituting 4 parts:

Now, let’s break these down simply.

Types of governance

1. Law and guidelines

The law is something we are all familiar with. It’s a set of rules imposed on us, usually by a government or sovereign entity in a particular, defined jurisdiction. Non-compliance with law often results in a punishment of some sort.

Importantly, however, laws are rules that you have a choice whether to follow. You can choose to break the law if you want to, if for example you feel a law is morally unjust, however there will be consequences for your actions. Laws act to deter people from breaking them. In this sense, they are guidelines that are enforced by punishment.

2. Principles and social norms

Principles and social norms are a fun specimen. They play on human behavioural psychology. The crux of governing through principles and social norms is that if you get enough people to do something, or believe something, the community will innately enforce that thing.

For example, it is not illegal to sing the entire musical of Les Miserables to yourself, rather loudly on the London Underground. In fact, it might make the London Underground a much more cheery place, were carriages to normalise singing. However, there is a social stigma against loud singing on the London underground. As a matter of principle and to enforce this principle, you will not be thrown into a jail cell, but you will receive a lot of cutting stares, disgruntled faces, and maybe someone whispering and gesturing for you to keep it down. Or for particularly awful singing, a tut.

The point is here, that people impose principles that are unwritten, because they follow the general herd mentality of a normalised society, from the perspective of that society.

3. Markets and Economics

Most things humans touch or have created in the world have a fiscal element. Or at least, you could probably make a strong argument that is the case. For this reason, when it comes to governance, there is generally a financial angle.

In this way, regulating markets and the price of something has a large amount of sway on whether something will be willingly followed. Tokenomics largely implement this for decentralised networks.

4. Architecture

Like law, architecture is something that sets the boundaries of what people can and cannot do. In the physical world for example, a locked door in a University signals that students cannot enter. The difference between law and architecture is that people do not have much of a choice to circumvent the architecture regulation. In this case, a student could purchase the tools to break through the locked door, but it would require a high degree of effort and force.

In digital domains, architecture becomes a much more powerful method of governance, as rules, boundaries and punishments can be coded into protocols themselves to deter or incentivise people. These architectural boundaries can be so strong that it can make it near impossible to avoid them. For example if you find a locked door in a video game, unlike in the physical world where it might be possible to break through it, in the digital world there may be no possible method of going through, and the door acts as a permanent and unbreakable barrier.

Coming back to the question: what is Governance?

Governance is a multifaceted concept, encapsulating each of the four parts, discussed above. It is a way of regulating behaviour and ensuring order in a given system.

All four of these parts weigh into one another, and different weightings can be applied to different Governance Frameworks.

For example, Governance set by governments relies largely on Law & Guidelines, to uphold order and less on Architecture.

This can be represented via the diagram below, which shows how government uses different quantities of the modalities to govern.

Whereas, the regulation of a Social Media Network relies much more on Principles & Social Norms and less on Markets & Economy.

This is represented in the diagram below.

In this sense, Governance is something flexible, which can be adapted for different use cases, based on a combination of factors such as, among other things:

1. Whether there is a clear jurisdiction;

2. Whether the system is in the physical or digital world;

3. Whether there is a currency.

How we define Governance

What is Decentralised Governance?

This is made possible because of the architecture of the Network, which enables the Network to become self-regulating and autonomous over time.

This is how the cheqd Network governance will look to begin:

Over-time the Network may vote to raise or lower these sliders, in accordance with group consensus.

One thing that will stand out looking at this chart is the lack of Law governing the Network.

In this way, the decentralised Network acts as its own Legislature, Executive and Judiciary, as decentralised consensus checks and balances each stage in the passing of a proposal.

A decentralised Network where accountability is spread out as such is often referred to as being sufficiently decentralised.

Primer on Principles-based Governance

The Principles listed in this Framework are designed to provide a functional reference point, and act as checks and balances, for cheqd community members and Network Users voting on the Network.

These Principles are specifically designed to govern Major Network Changes and ‘on-chain’ governance activities. They should serve as the foundation and baseline for the Network to build upon as it iterates and becomes increasingly decentralised.

Regulating through Principles-based Governance, as explained in Introduction to Governance, means that these are not hard rules. There is no single entity that can impose a punishment for failure to comply with these Principles. Instead these are suggestions to nudge Users on the Network to act within the best interests of the community, to be inclusive and to keep the Network secure. The Principles can be interpreted broadly, or narrowly, this is up to the discretion of the User and the community.

If the general consensus of the Network believes a Network Proposal is contrary to a Principle, they SHOULD feel inclined to reject or veto such as Proposal. This SHOULD keep the Network in check and within a set of boundaries to keep it developing in a healthy way. A decision by Network consensus MAY also incur a financial penalty on the User acting contrary to a Principle. In this way, the Network regulates behaviour through Principles as well as Economics using the Network's Architecture.

This type of Regulation, through norms and Principles is also flexible and can change quickly, as society and the Network develops. This is Unlike Laws and Guidelines which are far more static.

Updates, amendments or revisions to this Principles list can be made through the process explained in the section Major Network Changes.

cheqd Network Principles

Familiarise yourself with our set of principles for interacting with the network.

What is decentralised governance?

The principle concept of decentralised governance is that no single person, entity or organisation can control the direction of change in a public Network. Instead, the direction of change is agreed by the democratic votes of an ever-growing, diverse collective.

This point is desirable to reach, because it maximises Network security and resilience, creates an environment which is governed by a broad, diverse and multijurisdictional collective, and enables the Network to function purely as a utility, regulating itself through its own architecture.

However, this point is not something that can be reached overnight. There is a transition period between the genesis event of any decentralised Network and the point at which sufficient decentralisation may be claimed.

We want cheqd to achieve sufficient decentralisation, and to dissolve the initial control over the Network that few stakeholders may have. We want decisions to be made by the Network, and not by ourselves, the initial core team.

This is why we have created the concept of Entropy to transparently and effectively achieve sufficient decentralisation, through decentralised governance.

Entropy

Entropy is broadly defined as the degree of disorder or uncertainty in a system or process of degradation or a trend to disorder, according to the Mirriam-Webster Dictionary. In Physics, and specifically, the Second Law of Thermodynamics, its function is best explained through a metaphor succinctly delivered by Brian Cox.

Let’s think of a sandcastle sitting in a desert.

The sandcastle in the desert has both order and structure, and there are very few ways to arrange the sand grains to achieve the same structure.

Nearly anything done to the sandcastle will remove some of the order and structure of the sandcastle, gradually eroding the sand away from the familiar and notable structure.

For this reason, the sandcastle can be said to have Low Entropy because it relies on order, structure and design.

Conversely, a pile of sand with roughly the same amount of sand grains as the sandcastle has immeasurably more ways of ordering the sand to look like a pile of sand. This is due to the relative disorder of the sand pile.

For this reason, the pile of sand, with many more ways to arrange it, has High Entropy.

Now imagine that the sandcastle was left in the desert all day. The winds in the desert would blow the sand around, and it would slowly disintegrate and fall to bits.

However, there is nothing fundamental in the laws of physics that says that the wind could not pick up some sand from a pile and deposit it in precisely, the exact shape of a sandcastle.

It is just extremely, extremely unlikely because there are very few ways of ordering the sand so it looks like a sandcastle.

It is overwhelmingly more likely that the wind will take the Low Entropy structure, the sandcastle, and turn it into a High Entropy structure, the sand pile.

In short, physics says that Entropy always increases.

This same pattern and natural law can be seen in the development of decentralised governance. And if modelled correctly, a decentralised Network can be created so that Entropy always increases, gradually making the Network more and more decentralised.

The increasing of Entropy is one of cheqd’s foundational Principles, and we believe we can use it as a tool to achieve sufficient decentralisation efficiently and with transparency.

The genesis event

Like a perfectly formed sandcastle with Low Entropy, any decentralised ecosystem must begin with a structure, set of rules, parameters and default settings which govern the scope, boundaries and objectives of the Network — usually set by a small group of individuals.

For this reason every decentralised Network begins with a Low Entropy genesis event from which point Entropy increases.

This can be thought of like a Big Bang, starting a new system with a set of fundamental rules and boundaries.

Even the most high profile blockchains such as Bitcoin began with a notorious ‘genesis block’. Also known as Block 0, the Bitcoin genesis block was the first block created on the Bitcoin ledger, and every single Bitcoin block can have its lineage and ancestry traced back to it.

Interestingly, the next block, known as Block 1, wasn’t mined until six days after the Genesis Block. This is considered as a very strange occurrence for the protocol, since the general time gap between blocks is intended to be ~10 minutes.

Many have questioned why Satoshi Nakamoto, the infamous pseudonymous creator of Bitcoin, caused the delay. The most likely theory is that Nakamoto spent the first 6 days testing the protocol and its stability, before backdating the timestamp.

Others believe that Nakamoto wanted to play God and recreate the story of the world being created in six days… Just like the Big Bang, Nakamoto had to create a set of default settings and parameters for Bitcoin to develop autonomously.

The point of this elaboration, however, is to highlight that for every Network that eventually reaches a point of sufficient decentralisation and High Entropy, there is a Big Bang event, and a period of tinkering and adjustment, as Low Entropy begins to increase.

And this is where we started at cheqd.

At its mainnet launch, cheqd defined a set of baseline conditions and parameters for the cheqd Network, using Cosmos’ inbuilt decentralised governance capabilities and SDK.

Going forward, we want to clearly lay out how the Network will enable a smooth transition from a Low Entropy genesis event to a High Entropy, sufficiently decentralised structure.

How do we model Entropy?

To model Entropy, we wanted to build more visual and accessible than an algorithm or formula; something that could be easily applied to multiple blockchains and utilised by any layperson and diverse audience .

Where we landed was: a Scorecard

The spider diagram above, the Entropy Scorecard, shows a scale scoring from 1 - 5 which we refer to as Entropy Levels, measuring tangible decentralisation from a genesis state (and Low Entropy) to beyond the point of sufficient decentralisation (and High Entropy).

At each point on the diagram sits a different metric of measurement. It is important to note that we could have selected more, fewer or different metrics to calculate Entropy against. We chose the seven metrics listed below because they provide a very sensible, digestible foundation for a rough calculation of cheqd’s Entropy. These metrics cover each angle of the Network, from security to geography to utility to governance.

We would absolutely welcome suggestions and feedback from the community to further refine this list going forward. You can start a thread using our Discussion Forum on Commonwealth.

We will walk through our reasoning behind each choice:

Validators (number)

This is the number of Node Operators on the Network. This is significant because the composition of Node Operators on the Network has a direct relationship with the dilution of voting power. The greater the number of Node Operators, the:

1. Greater choice the token holders have in who to bond and delegate tokens to for the purpose of Network Governance.

2. Greater the strength of security on the Network, with fewer points of failure.

Developers (commits)

This is the number of commits made on the source code after launch via cheqd’s open source repositories. Ideally, we would also be able to measure the amount of commits made by developers outside the core team of cheqd. Commits from developers outside cheqd add healthy randomness to the code and the development of the Network.

Participants (number)

This is the number of bonded token holders, meaning the Network Users who have bound a portion of their tokens to a Node Operator in order to participate in Governance.

This is important because the larger the pool of Participants, the more the voting power will become diluted across the Network, since Participants are able to vote unilaterally, regardless of the Node Operator they are bonded to.

Nakamoto coefficient (number)

Taken from previous work done on blockchain decentralisation, this is the minimum number of Entities in the Network that can pool together to reach 51% stake on the Network. The higher the number here, the more the Network is secure against malicious attacks and undesirable breaking changes.

Exchanges (volume)

Exchanges are closely correlated with the accessibility of the token. Being able to buy and sell CHEQ on an exchange will open the token up to a larger range of Users. A higher number of exchanges will lead to a healthier split of stake, with hypothetically, lower volume across each exchange.

Nodes (country)

The geographical makeup of the Network is important when discussing decentralisation. This is because geographic diversity lends itself to diversity of thought and perspective. Furthermore, a geographically diverse Network increases the security because even if an entire country was to shut its infrastructure down, a multijurisdictional Network would continue resolutely.

Proposals (number)

Like developer commits, Network Governance Proposals transition the Network away from its genesis state to a more random and disordered Entity. This again is very important in removing the initial control and order that the cheqd core team has implemented into the genesis state of the Network.

The Proposal and Voting process on cheqd is based on a liquid democracy. As a result, the more decisions are made through this process, the more control is taken away from a centralised collective and moved to the consensus of a wide-barrelled and diverse group of Participants.

Calculating Entropy

Having laid out the distinct metrics used to constitute Entropy, it is next important to lay out the values that define each Entropy Level. These values are specific to cheqd and the levels of decentralisation we would like to eventually reach.

These values have been calculated by us looking at our end-goal, taking the point at which we feel we could be maximally or sufficiently decentralised, and scaling backwards.

The values that we have chosen are as follows:

To ‘score’ Entropy, you need to add the total sum of the Entropy Level across each metric.

For example, the highest level of decentralisation a Network could reach according to this model would be Entropy Level 5 in all metrics - totalling a score of 35. Whilst the lowest level a Network could have would be Entropy Level 1 in all metrics - totalling a score of 5.

We would also love to see other Networks applying the same scorecard model of Entropy to exhibit their Network’s level of decentralisation, and whilst slight changes may need to be made to accommodate for nuances in different Networks, the core concept can remain the same.

Over time, we do expect this initial table to be iterated, extended and revised as decentralised ecosystems in general become more mature, more distinct and as opinion from Regulators, such as the Security and Exchange Commission (SEC) becomes more clear.

Entropy Progression

In this section we want to explain where we are, where we want to get to, and why we want to get there.

Where we started

Like any other blockchain Network, cheqd began its life cycle with a Low Entropy score. This is absolutely normal for the genesis of a decentralised Network, as the core team will have put in the default parameters, meaning there will be a higher locus of control, and change has not yet been made via the governance framework processes.

At launch our Entropy score was lower than 14.

A low entropy score as such, can be represented by the scorecard below:

This score quickly began to shift after launch as more participants joined from different geographies and stake began to spread more evenly. We will soon be launching a Governance Dashboard which shows where the network is on this scale.

Where we want to get to

We are aiming for high Entropy for various reasons, because it:

1. Correlates with higher Network security and resiliency across countries

2. Means broader contributions to the Network from a multidisciplinary and diverse collective

3. Enables increased integration capabilities with other technologies to improve the ecosystem as a whole

4. Increases the democratisation of wealth and dilution of rewards across a larger scope of actors

5. Dilutes the control from a select group of people, to a genuinely decentralised and diverse collective.

As a benchmark, we want to aim for an Entropy Score greater than 28; and with none of the scores below Entropy Level 3.

This combination is important because it will ensure that there is limited surface area for centralisation or control, as all metrics have progressed beyond a Low Entropy state.

A High Entropy Network would generate a scorecard illustrated by the example below:

At this point of High Entropy, we would hope that we would be considered a Network which is sufficiently decentralised, although of course this is not up for us to decide. Yet, we believe that this progression of Low to High Entropy is an important journey for every decentralised Network to embark on.

How do we plan to get there?

To increase Entropy, we have developed a governance framework that champions decentralisation as time progresses.

Achieving high Entropy involves:

1. Making it easy for Node Operators to onboard in an Open Source way

2. Having clear and transparent documentation, in multiple languages

3. Having simple governance processes to evolve the Network baked into the protocol

4. Incentivising a healthy community, with places to discuss positive and constructive ideas

5. Enabling all parties to be remunerated for their active contribution and participation

And a combination of the above will increase the Network Entropy in a healthy and natural way, bridging the middleground between Low and High Entropy, as seen below:

As the initial team, we have a responsibility to, as we like to put it, create the first domino and push it over. Or in other terms, we need to take care in setting a strong technical foundation alongside a culture of transparency, inclusivity and open communication to push Entropy in the right direction.

Where does this leave us?

We have introduced and explained the following:

1. Why decentralisation is an important goal for healthy blockchain Networks;

2. Why Increasing Entropy is crucial to achieving this goal;

3. How to model Entropy to achieve greater clarity.

And looking back now, what we want the reader to take away from this is to understand the following:

Decentralised Networks and protocols often leave a lot to be desired, especially when it comes to clearly defined lines.

Through our model of Entropy, we incentivise healthy behaviour, high resiliency, and utility which should be the building blocks for any decentralised Network.

We also want this to move decentralisation towards greater regulatory clarity, rather than towards greater dissonance.

If we want to make self-sovereign identity, rooted on a decentralised Network a reality, we can only do this through being open, creative and inclusive in the way we work. Helping frame decentralised ecosystems in a way which makes sense for laypersons will bolster the chances of SSI and token payment rails being used in regulated industries worldwide.

The model of Increasing Entropy, as one of cheqd’s Foundational Principles, attempts to build greater clarity around the labelling and framing of decentralised ecosystems and DAOs. We hope the community can iterate and build on the work done here and respond with feedback and opinion. This eventually can create an even more robust framework and help make cheqd’s vision of a Web 3.0, the new paradigm for human interaction.

Entropy dashboard

Our friends at observatory.zone have built a dashboard to monitor cheqd's levels of decentralisation and entropy, below: