GOVERNANCE
Governance is not settled, and will not be settled early.
No governance mechanism exists. This page says who decides today, what governance would eventually cover, and why the architecture has not been chosen.
01 · HOW DECISIONS ARE MADE TODAY
How decisions are made today
Stated first, because a governance page that describes only future governance is making a claim by omission.
The core team decides, unilaterally. There is no mechanism for anything else yet.
Protocol changes, parameters and priorities are set by the people writing the code. No vote binds that, no proposal process constrains it, and no token confers a say. That is the state of a network whose mainnet has not launched and whose governance is unimplemented, and it stays true until one exists.
The stated direction. Kronex governance should progressively include developers, infrastructure providers, users and the broader ecosystem. Progressively is the operative word, and it is a direction rather than a schedule. No stage of it has a date, and none of it is built.
02 · WHAT GOVERNANCE WOULD COORDINATE
Seven subjects
What a governance process would eventually decide about. The source names these seven and describes none of them.
- 01protocol upgrades
- 02marketplace standards
- 03network parameters
- 04treasury allocation
- 05ecosystem funding
- 06new provider classes
- 07research initiatives
These are subjects, not participants. The seven participant roles on /ecosystem are a different list about different things, and neither maps onto the other.
03 · WHY IT IS NOT DECIDED YET
Why it is not decided yet
The precise governance architecture should evolve alongside the network rather than being prematurely centralized into token voting.
- What prematurely protects against
- A governance mechanism chosen before the network has participants encodes whoever holds the most of something early. Token voting on a chain before mainnet launch would hand the protocol to its initial distribution, then call the result community consent. It is also difficult to undo: a mechanism becomes the thing that has to approve its own replacement.
- What has to be true first
- There have to be participants with something at stake — providers serving orders, developers depending on the APIs, users whose work runs on it. A process that coordinates those interests can only be designed once they exist to be coordinated.
Until then the honest position is that the question is open. This is a refusal to commit, not a commitment deferred — the source declines to promise token voting, and so does this page.
04 · KRONEX IMPROVEMENT PROPOSALS
Kronex Improvement Proposals
A KIP is the written form a protocol change is meant to take — a proposal that can be read, argued with and pointed at, rather than a decision that appears in a release note. The mechanism, its categories and its review states live on their own page.
05 · WHAT IS UNDECIDEDSpecification pending
What is undecided
Named as a list rather than hedged through the prose. A page whose subject is undecided is stronger for saying where.
- 01Who votes, and on what basis they are entitled to.
- 02What is in scope for a vote and what stays with whoever maintains the code.
- 03What weight a participant carries — per person, per stake, per contribution, or something else.
- 04How a decision binds, and what happens when it is ignored.
- 05Whether KRNX has any governance function at all.
Whether the network asset has any governance function at all is among these. KRNX's utility list names governance participation as an intended role; whether that becomes a vote, a signal or nothing is not decided.
Related