In one paragraph

Theseus governance is validator-based and designed for operational speed — ship upgrades quickly, respond to issues, preserve decentralization through delegation and transparent proposals. Once a proposal passes, the new runtime is enacted in the next block. No hard forks, no validator binary updates, no coordination calls.

Forkless upgrades: the runtime (compiled to Wasm) is replaced on-chain via set_code. Validators don’t need to download new binaries.
Grace period + delegation: every proposal has a 12–24h grace window for direct votes; un-voted validators fall back to their designated delegate.
Bounded scope at alpha: runtime upgrades, prover-set changes, validator-set changes. No token-weighted voting yet.
Replaces the sudo model: no single key has unilateral authority once governance is enabled.

Forkless runtime upgrades

One of Substrate’s most powerful features: the chain’s logic, compiled to Wasm, can be replaced on-chain via the set_code mechanism — without requiring validators to download new binaries or coordinate a hard fork. Theseus leverages this so upgrades are fully automatic. Once a proposal passes, the new runtime is enacted in the next block.

The mechanic is the same one that lets the chain ship a new pallet, change a parameter, or fix a bug at the runtime layer: you don’t coordinate a node-software release, you ship Wasm.

Proposal flow

Submit: a proposal is submitted on-chain with the new runtime Wasm or the parameter change.
Open + grace window: validators have 12–24 hours to inspect the upgrade and vote directly. No outcome is tallied during the grace window.
Delegated vote (after grace): any validator that hasn’t voted directly falls back to their designated delegate’s vote (if any). If neither has voted, no vote is cast for that validator.
Tally: votes are counted. Majority yes auto-enacts in the next block. Majority no rejects the proposal.
Enactment: the new runtime takes effect automatically; state is preserved.

Vote delegation

With only four validators at alpha, governance has to stay responsive — a single offline or slow validator shouldn’t block a critical upgrade. Delegation handles that without removing the validator’s right to override.

Each validator can designate another validator as their delegate.
On every proposal, the delegate’s vote is only applied after the grace period and only if the delegating validator hasn’t voted directly.
The delegating validator can override at any point inside the grace window by voting directly.

Default behavior in practice

If three validators trust the Theseus operator’s judgment on routine upgrades, they can delegate to it and only vote actively when they want to inspect or reject something. Each still keeps a unilateral override.

Scope at alpha

Governance covers three categories of changes today:

Runtime upgrades

New pallets, logic changes, parameter updates.

Prover set

Adding or removing provers from the registered set.

Validator set

Adding or removing validators.

This replaces the initial sudo model — a single admin key with unilateral authority — with a multi-party system where no single entity can push through changes alone.

Where this goes

Beta expands the validator set and introduces $THE-weighted voting for certain proposal types, backed by validator and prover staking.

Mainnet targets full token-weighted governance with community participation and longer deliberation periods for major changes. The validator-only mechanic at alpha is scaffolding — the path to community governance is the same forkless mechanism, with a wider electorate.

← Security

The trust scope governance shrinks.

Status & Roadmap →

The phase plan governance ships against.