Verifiable governance

TKMChain governance is represented by explicit chain state, signed authorizations, checkpoints, and activation rules. Node operators can verify the same state instead of trusting a dashboard or a private administrator.

Open the explorer · Read the protocol source

Main King and Rotating Kings

The chain configuration identifies the Main King and any active Rotating King set. Rotations occur on a defined interval and are validated by consensus. These roles authorize protocol operations; they do not hold user spending keys or bypass Shield3 proof checks.

Register a Rotating King

A funded ML-DSA-87 account can register itself from the interactive console wallet. Start a node and run:

./gtkm wallet interactive

Choose Kings, then press r. Select the local account, review the active stake requirement and fee reserve, and type REGISTER to submit the local rk_add request. The wallet signs through the node's IPC endpoint; it does not send the account password or private key to the RPC server. Save the returned registration hash for cross-node verification.

Use s to inspect one registration by local account number or address. The status view includes the chain-bound registration hash, locked amount, added height, unlock height, and whether the account is current or next. The Kings screen also lists registrations and recent rotation history automatically. The same information is available to operators through rk_list, rk_status, and rk_getKingStats.

Before Antartical the legacy minimum stake is 50,000 TKM. At Antartical it is 100,000 TKM, plus the existing 1-TKM registration fee reserve. Egypt (chain

record checked by consensus; it does not debit an account outside a block. If the account later spends below the active requirement, it is pruned from the rotation schedule.

1. runs the post-fork rule from genesis. A registration is an eligibility

Checkpoints and the permanent boundary

The mainnet checkpoint boundary through block 41913 is permanent. Nodes reject a history that rolls back below that boundary or presents a mismatched checkpoint hash. This protects recovery, synchronization, and release builds from accepting an incompatible chain history.

Consensus block-hash anchors

TKMBlockHashAnchors is the operator-facing event mirror. The mandatory consensus rule is implemented in the RandomX header validator: every Antartical block must carry a fixed block-hash anchor suffix. Nodes reject a missing, malformed, wrong-parent, wrong-height, or incorrectly chained anchor during mining, header sync, block import, and reorganization checks. The contract is also installed as a deterministic consensus predeployment at 0x0000000000000000000000000000000000008979 when Antartical state processing begins. Egypt performs that transition from genesis; mainnet performs it at activation. Miners and importers apply the same state transition, so no transparent deployment transaction is required and the privacy gate is never weakened. The contract remains useful for an event-indexed record; its owner can call appendVerified(height, expectedHash), appendCanonical(height), appendParent(), or appendVerifiedRange(...). Before each value is stored, the contract compares it with the EVM BLOCKHASH result. Anchors are contiguous after the first entry, and there is no delete, overwrite, upgrade, or self-destruct path. A domain-separated rolling commitment covers the full sequence, while BlockHashAnchored events can be checked by explorers and independent nodes.

All append methods activate at Antartical: mainnet chain 8979 uses 1 October 2026 00:00 UTC (1790812800), while Egypt chain 8980 is active from genesis. Unknown chain IDs remain disabled.

The EVM can only verify the previous 256 blocks. The contract therefore rejects older hashes instead of trusting an owner-supplied historical list. The header commitment is the consensus source for the complete post-fork sequence; the contract is an auditable mirror. Proof-of-work still requires checkpoints or a finality rule for economic finality against a fully recomputed competing chain.

Antartical activation

Hardfork rules are activated from the configured chain timestamp and height. Nodes validate the activation state before accepting Shield3, stamping, sponsorship, and post-quantum account features. A release must report the same chain configuration as its peers.

Validator registry and operator view

Validator registration is a consensus transaction. The sender must be an ML-DSA-87 account and the transaction locks 500,000 TKM while burning the 100 TKM registration fee. The account therefore needs 500,100 TKM plus its transaction fee reserve. The record activates only after a 720-block queue, is selected deterministically from the parent hash and height, and earns the halving-aware 70 TKM validator share. A validator can submit a signed exit; the bond becomes withdrawable only after the 21,600-block unbonding period. Conflicting signed attestations burn the remaining bond and jail the record.

The complete operator procedure, envelope fields, reward table, exit and slashing rules are in Validator registration. The protocol payloads are TKMVALREG1 (registration), TKMVALEXIT1 (exit), TKMVALWD1 (bond withdrawal), and TKMVSLASH1 (equivocation evidence). A registration is a PQTkmTxType to the reserved Shielded Pool address with exactly the bond as its value; it is not an ordinary EVM call.

The initial Antartical reward schedule totals 200 TKM per block: 90 TKM to the RandomX miner, 70 TKM to the selected validator, 35 TKM to the Rotating King, and 5 TKM to the Main King. The existing halving interval is applied to all four shares together. Reward markers are validated against the selected record and block height, so a forged recipient or amount makes the block invalid.

Explorers and operators should treat the node's tkmprotocol response as the source of truth. tkmprotocol_antarticalStatus reports the canonical head and activation state, while tkmprotocol_antarticalFeatures reports each feature's active and consensus-ready flags. A registry endpoint may be unavailable on an older node; in that case the explorer must show the registry as unavailable instead of displaying guessed validator addresses.

The slot-level witness path is active for deterministic optimistic transfers: read slots are checked against their pre-state values before a write-set is committed, and the sorted slot sets are included in the versioned conflict transcript. Contract calls and creates stay serial until their dynamic witness coverage is complete. This boundary keeps a partially implemented execution engine from becoming an accidental consensus fork.

Sponsorship

Sponsorship lets a registered operator pay execution fees for a bounded private operation. The authorization commits to the chain, operator, nonce, gas, expiry, beneficiary, stamp, encrypted outputs, and proof. Operators can submit a payment but cannot alter its private recipients or open its notes.

Address votes and investigations

After Antartical, a stamped account can submit a public address-vote envelope with a bounded reason such as fraud. Each registered stamp owner gets one active vote per target, even when that owner controls multiple addresses. Fifteen distinct active stamp owners suspend the target from sending or spending. The target is not erased and its history is not rewritten.

Every vote and unvote burns 50 TKM from the stamped voter. The envelope still carries zero transaction value and the burn is destroyed by consensus, so it is never credited to the target, a treasury, or another account. The voter must fund gas and this burn separately.

The voter can later submit gtkm governance unvote --from <stamped-address> --address <target> to remove its own vote. When the count drops below fifteen, consensus clears the suspension marker. Use gtkm governance status --address <target> or tkmgov_getAddressVoteStatus to inspect the canonical count. Reasons are carried by signed transactions so investigators can review them; a vote is an allegation, not a finding of guilt.

Each node also maintains a block-derived audit projection at ~/.tkmchain/gtkm/governance/address-votes.json. It records vote reasons, voters, target addresses, transaction hashes, and block references. The file is rebuilt from canonical blocks after restart or reorganization and cannot override consensus state; deleting it is safe.

Operating a verifier

Run a full node with the published chain configuration, keep the database backed up, and compare checkpoint and activation logs with another independent node. Governance data is useful only when its signatures, timestamps, and state transitions are verified locally.