XE Governance
Holders decide. The chain enforces it.
XE holders set how the network runs. Every change lands on the XE State Chain as a block signed by the XE Keyset, checked by every node and readable by anyone.
Who holds XE runs XE. Not by a foundation’s say-so or a thread on a forum, but by signed blocks on a chain every node checks.
A handful of settings decide how the network behaves: how much XE a job mints, how much revenue buys XE back and burns it, and which contracts, images and nets machines are offered. Those settings belong to the people who hold XE.
What holders decide becomes a fact on the XE State Chain, the network’s rulebook as a chain of its own, kept apart from the ledger. Change a parameter and the network changes with it, without a new release or a hard fork. What governance can’t do matters just as much: it can’t move your XE, settle a double spend or drop below two signatures.
XE holders vote on how much XE work mints, how revenue splits, and what’s approved.
The XE Keyset jointly signs each change onto the chain, and never with fewer than two keys.
Each node verifies every block for itself and applies it the same way, to the same state.
The settings that decide
how XE behaves.
Three levers set how the token works. Beneath them sit the network’s own parameters, and the keyset that signs every change, including changes to itself.
- What holders set
- How much new XE a unit of paid work mints, for the machine that did it and the holders behind it.
- The guardrail
- What’s minted for a job stays worth less than the job costs, so faking work together never pays.
- Today
- A fixed rule in the protocol. Emission as its own coefficient is in design.
What no vote can touch.
Governance tunes the network. It doesn’t get to rewrite the guarantees. These hold whatever the XE State Chain says, because they’re in the code every node runs.
Only your key can add a block to your chain, and every node checks that it did. The XE State Chain holds settings, not balances. It has no operation that can move anyone’s XE.
Settings only: set · deleteConflicts are settled by XE Consensus, not by governance: representatives weighted by delegated XUSD vote only when an account contradicts itself.
67% of the vote decidesHow XE Consensus works
No block can set a threshold below two or delete a system key, however many sign it. The floor is checked when a keyset is written and again whenever it’s read.
Never fewer than 2 signaturesThe XE State Chain is one line. A second block for a place already taken is refused and raises an alert, and the chain never switches branches.
fork → reject, alert, keep the tipFrom a proposal to
a fact on every node.
A change is written exactly as it will apply: the keys it sets or deletes on the XE State Chain, and their values. Nothing is left to interpret later.
{ "action": "set", "key": "config.emission_rate", "value": 100 }XE holders vote on it. Proposals and their results are public, on chain.
minting · the revenue split · approvalsEach member of the XE Keyset seals exactly what the block does, with XE Signatures. It goes nowhere until the threshold is met, and never on fewer than two.
Sealed by each signer’s own keyEvery node checks it for itself: that it’s unaltered, its place after the tip, each operation, that every signer is in the keyset and signed once, every signature, and the threshold.
Valid signatures ≥ the thresholdIts operations apply in order, and every node reaches the same state. Nodes that were offline catch up from their peers. No release, no hard fork.
Carried to every node by XE MeshFrom a proposal to
a fact on every node.
- 01Propose
A change is written exactly as it will apply: the keys it sets or deletes on the XE State Chain, and their values. Nothing is left to interpret later.
{ "action": "set", "key": "config.emission_rate", "value": 100 } - 02Vote
XE holders vote on it. Proposals and their results are public, on chain.
minting · the revenue split · approvals - 03Sign
Each member of the XE Keyset seals exactly what the block does, with XE Signatures. It goes nowhere until the threshold is met, and never on fewer than two.
Sealed by each signer’s own key - 04Verify
Every node checks it for itself: that it’s unaltered, its place after the tip, each operation, that every signer is in the keyset and signed once, every signature, and the threshold.
Valid signatures ≥ the threshold - 05Apply
Its operations apply in order, and every node reaches the same state. Nodes that were offline catch up from their peers. No release, no hard fork.
Carried to every node by XE Mesh
Try to push a change through.
An XE State Chain block, and the six checks every node runs before it applies one. Sign it with the right keys, or try every way around them.
- index
- 42
- prev_hash
- 3c0fdb1a…7f9dd6
- timestamp
- 1790155267000000000
- ops
- { action "set"key "config.emission_rate"value 100 }
- 01HashThe operations still match the block’s hash
- 02PlaceThe next index after the tip, linked to its hash, not stamped earlier
- 03OperationsWell-formed keys, valid JSON, and the rules for system keys
- 04SignersEvery signer is in the current keyset, and signs once
- 05SignaturesEvery signature is genuine, and covers this exact block
- 06ThresholdAt least 2 signatures, the current keyset’s threshold
Built so it can’t
be captured.
Every obvious way to seize or bend governance on XE, what the protocol does about it, and the rule that stops it.
Rotate the keyset down to a single signer, then change whatever you like.
A keyset can never need fewer than two signatures. The floor is checked when a keyset is written, and again every time it’s read, so not even a keyset written by an older version can slip under it.
Never fewer than 2 signaturesThe XE KeysetWhat’s live, and what’s next.
The machinery of governance runs on testnet today. Some of what it will govern is still being designed, and we say which.
- The XE State ChainOne line of jointly signed blocks, replayed by every node and synced between peers.v0.3.0
- The XE KeysetA group of keys that sign together, never fewer than two, checked on write and on read.v0.3.0
- The governance APIThe tip, every block, every key and value, and the keyset, from any node.v0.3.0
- DAO console and state inspectorDraft, sign, collect and submit from the wallet. Browse every block and value.v0.3.0
- XE Timekeepers, set by governanceThe nodes that witness lease times are listed on the XE State Chain. Machines won’t take work without them.v0.4.1
- PlannedHolder votes on the three leversMinting, the revenue split and approvals, decided by holders and carried onto the chain by the keyset.Planned
- In designEmission as its own leverSeparate settings for what compute costs and how much XE it mints, both held on the XE State Chain.In design
- In designPricing on the XE State ChainLease rates are fixed in the protocol today. Once they’re on the chain, changing them needs no release.In design
- DesignedEmission by strength of proofFull emission for uptime both sides signed, less for proof the customer never reviewed.Designed
- DesignedExtra uptime checks, on a switchExtra protection against faked uptime, ready for governance to turn on if the economics ever change.Designed
Every decision is
a block you can read.
Governance on XE isn’t a document. It’s a chain of its own: one line of signed blocks, kept apart from the ledger, holding the settings every node runs on. Ask any node.
1export XE_NODE=https://ldn.core.test.network23# who signs, and how many signatures it takes4curl $XE_NODE/statechain/keyset56# {7# "keys": ["a1b2c3d4...", "e5f6a7b8...", "c9d0e1f2..."],8# "threshold": 29# }
Straight answers.
What holders, signers, operators and builders ask about how XE is run.
How is XE governed?
XE holders decide the settings that shape the network: how much XE is minted for work, how revenue is split, and which contracts, images and nets are approved. Each decision is written to the XE State Chain as a block jointly signed by the XE Keyset, then checked and applied by every node.
What can XE holders vote on?
Three levers: how much XE a unit of paid work mints, the share of revenue that buys XE back and burns it each week (40–50% today), and which contracts, images and nets are offered to machines. Beneath them sit the network’s parameters and the XE Keyset itself, all held on the XE State Chain.
What is the XE State Chain?
The network’s rulebook, as a chain of its own, separate from the ledger that carries payments: one line of blocks, each a list of changes to the network’s settings, each jointly signed by the XE Keyset. Every node replays it from the start and reaches exactly the same state.
What is the XE Keyset?
The group of keys that must jointly sign every rule change, and how many signatures a block needs. It’s stored on the XE State Chain itself. It can never need fewer than two signatures, and it can only be changed by a block the current keyset signs.
Can governance move my XE?
No. Only your key can add a block to your account’s chain. The XE State Chain holds settings, not balances, and has no operation that transfers anyone’s funds.
Can one person take over XE governance?
No block can set a threshold below two, and every signature has to come from a distinct key already in the keyset. A new keyset must be signed by the one it replaces, and system keys can’t be deleted.
Does changing a network parameter need a hard fork?
No. A change is a signed block on the XE State Chain. Every node checks and applies it, and nodes that were offline catch up from their peers.
How do I check a decision for myself?
Ask any node. GET /statechain/keyset returns the keyset, /statechain/kv every setting, and /statechain/tip and /statechain/blocks the history. The explorer and the wallet’s state inspector show the same blocks and values.
Is XE governance live?
The XE State Chain, the XE Keyset, the governance API and the wallet’s DAO console have run on testnet since v0.3.0. Holder voting on the levers is planned, and emission and pricing as governed parameters are in design.
How is governance different from consensus?
XE Consensus settles double spends: representatives, weighted by delegated XUSD, vote only when an account signs two blocks for the same place. Governance sets the network’s parameters on the XE State Chain. Neither can do the other’s job.