We hold a key.
Here is its scope.

At genesis, a multisig we control can push time-locked patches to two components: the new graphics-card mining puzzle, and the router between the two contract engines. That is a real point of centralisation, and saying otherwise would be worse than having it.

So the rest of this page is the specifics. Exactly what it reaches, exactly what it does not, why it cannot act without warning, and the conditions under which it stops existing.

The full specification What else we run

It reaches: Two components; the GPU mining lane and the router
It cannot reach: Everything else; enforced in the contract, not in a policy
Notice: Time-locked; visible on-chain before it takes effect
It ends at: Written thresholds; then ordinary community governance

The four questions

Why, what, what not, and when it stops

These are the questions anybody sensible asks when a project admits to holding a key. They are answered in that order because that is the order they matter in.

1 · Why it exists at all

Two components here are genuinely new: the graphics-card mining puzzle and the piece that lets the two contract engines call each other. Shipping either with no ability to fix it means that a critical flaw found after launch can never be fixed. That is not a principled position. It is a way to lose a chain.

2 · What it can reach

Those two components, and nothing else. Not a category of things like them, not anything adjacent to them. Two named contracts. The list is in the animation above and it is the whole list.

3 · What it cannot

Balances, the emission schedule, the supply cap, the exchange, the Compute Mesh, either registry, and governance itself. That boundary is enforced in the governance contract rather than promised in a document, and widening it is a governed action rather than something we can do quietly.

4 · How it ends

At decentralisation thresholds written into the contract, the capability sunsets and those two components fall under ordinary community governance like everything else. The part that usually goes wrong with this promise is that the sunset is left vague. Ours is a condition, not an intention.

The obvious objection

Why not simply have no key

It is a coherent position and plenty of people hold it. A chain with no administrative capability anywhere cannot be interfered with by its founders, and that is genuinely worth something.

The cost is that it also cannot be repaired. Two components here have never been attacked at scale because they have never run at scale. If a critical flaw turns up in the mining puzzle three months after launch, a chain with no patch path has one option, which is a contentious hard fork under time pressure while the flaw is being exploited.

So the choice is not between having a centralisation point and not having one. It is between a narrow, disclosed, time-locked one that covers the two things most likely to need it, and an emergency response improvised in public later. We took the first. If you would have taken the second, that is a reasonable disagreement and you now have the information to have it.

The scope, written out

the multisig may patch
    the tensor-memory-hard mining lane
    the cross-VM router

it may not touch
    balances                any account, ever
    emission                the schedule or the rate
    supply                  the fifteen billion cap
    the exchange            order book or pools
    the compute mesh        staking, jobs, slashing
    the registries          founders or referral
    governance              including this scope

every action
    is announced on-chain before it can run
    is visible to anybody watching, in advance
    has no same-block override

widening the scope
    is itself a governed action

The timelock length is set in the governance contract. It is not stated here because that contract is not written yet, and putting a number of days on this page before it exists would be inventing one. It gets published with the contract.

The part we would rather you heard from us

There is a second centralisation point, and this page used not to mention it. Changes at the consensus level, meaning the ordering rule and the parameters underneath it, stay with the core team until the network has enough independent miners and validators that governance capture is not a realistic worry. That is a wider power than the emergency key and it is held for longer. Moving that boundary is itself a later governance decision.

Any project can move a threshold by changing what the threshold means. A sunset condition written by the people it constrains is worth exactly as much as their willingness to honour it. We know that, and so should you.

What you can actually check. The scope is enforced in a contract rather than in this paragraph, so read the contract when it is published rather than taking this page's word for what it says. Every use of the capability, and every stretch of time it goes unused, is visible on-chain. And every change to this page is dated in the public changelog, so hold us to the version you are reading now rather than to whatever it says later.

The GPU mining laneOne of the two components the key can reach, and why it is new.The routerThe other one, and why it ships at launch rather than after.

We hold a key.Here is its scope.