TKTKMChain

TKMChain field notes

This is the working guide for the network. It explains what is shipping, how to use it, and where a node operator can verify the behavior in source and consensus state. The English Markdown is the canonical copy; the site build publishes it under every language route while reviewed translations are added to each catalog.

What we are building

A TKM-native EVM profile

TKM keeps the EVM execution and ABI surface so existing tools can be used, but it does not treat every ERC-shaped contract as a TKM asset. The new TKMASSET runtime trailer commits a contract to the chain ID, token kind, capabilities, policy hash, name, symbol, and metadata. Wallets and explorers can call tkmasset_getAsset to distinguish a verified TKM-20, TKM-721, or TKM-6909 asset from an ordinary ethereum-compatible contract.

The TKM asset ID is domain-separated and binds the contract address, so identical source code deployed at two addresses cannot share an identity. The Antartical-gated 0x...f3 precompile computes that ID without reading state. This is an identity and policy layer; it does not grant minting or upgrade authority, and capability flags must still be enforced by the contract.

Try the builder from a local node:

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"tkmasset_buildManifest","params":[{"chainId":"0x2313","kind":"fungible","decimals":18,"flags":9,"policyHash":"0x0000000000000000000000000000000000000000000000000000000000000000","name":"TKM Dollar","symbol":"TKMD","metadataURI":"ipfs://tkm/asset.json"}]}'

The TKM EVM profile guide has the classifier response, Solidity helper, deployment checklist, and security invariants. “100% unique” is not a useful technical promise while retaining EVM compatibility; the profile makes the TKM-native layers explicit and verifiable instead.

Antartical execution profile

The Egypt rehearsal now covers the complete profile primitives in consensus/antartical/profile.go:

verification preserving the post-quantum account policy.

pause, royalty, and shielded operations.

verification path.

the canonical interpreter.

  1. Chain- and contract-bound typed transactions, with ML-DSA-87 sender
  2. Policy commitments bound to manifests, followed by enforced mint, burn,
  3. A canonical asset-registry root, carried in versioned header metadata.
  4. Shield3/Shield4 asset and token-ID nullifier bindings.
  5. Independent EVM, TVM, proof, and blob gas dimensions with overflow checks.
  6. Deterministic parallel waves and receipt-index conflict metadata.
  7. Sorted stateless witness commitments and a finality-backed light-client
  8. Alternate EVM admission only after differential conformance vectors match

Run the check from the Go repository with go run ./cmd/egypt-contract-test. It uses an in-memory chain-8980 state, never touches the production data directory, and prints the commitment values and checks as JSON. The old receipt RLP and historical witness commitment remain available; changing those wire encodings requires a coordinated network upgrade rather than a local configuration switch. params.Rules.TKMProfileVersion keeps those legacy encodings at version 0 and selects the new metadata at version 1 when Antartical activates (Egypt uses version 1 from genesis).

The Egypt rehearsal now deploys EUSD, a six-decimal TKM-20 fixture. It mints 1,000 EUSD, transfers 250 EUSD, verifies balances and total supply, parses the runtime manifest, and confirms that the direct asset ID matches the Antartical asset-ID precompile. Egypt node data is kept in ~/.tkmchain-egypt by the checked-in launcher so this test cannot reuse the production database.

Validator operations and slot-level witnesses

Antartical validators are registered by a consensus PQ envelope, not by an ordinary contract. A registration locks a 500,000 TKM bond, burns the 100 TKM registration fee, and enters a deterministic 720-block activation queue. Active records are sorted by address and selected from the parent hash and height; the selected validator receives the 70 TKM share of the 200 TKM block reward schedule. Exits, the 21,600-block unbonding period, equivocation slashing, and reward-marker checks are all state transitions, so a wallet or alternate EVM cannot bypass them.

The optimistic execution path now records deterministic slot-level witnesses. For each speculative transaction the node captures the first pre-state value read for every storage slot and the final value written. Commit validation rechecks those reads against the canonical state before applying the writes and includes the sorted slot sets in the versioned conflict transcript. Simple code-free transfers can use this path; contract calls and creates remain on the serial path until their complete dynamic witness is admitted by consensus.

The daemon exposes the same machine-readable feature catalog to operators:

curl -s http://127.0.0.1:8545 \
  -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"tkmprotocol_antarticalFeatures","params":[]}'

The remaining four upgrades are deliberately gated: parallel contract execution, enforced stateless Verkle headers and sync, bundled Revm/evmone backends with differential vectors, and byte-compatible native EIP-4337/ RIP-7560 execution. Their catalog entries and acceptance tests are visible, but nodes do not claim them as production consensus until the Egypt and multi-node rehearsals pass.

For the operator-facing registration sequence, see Validator registration. The current release is v1.21.62. Its consensus registry uses a 500,000 TKM bond, a 100 TKM burned registration fee, a 720-block activation queue, deterministic parent-hash selection, a halving-aware 70 TKM validator share, voluntary exit, 21,600-block unbonding, and evidence-based slashing. This page and the explorer must report those values from canonical state rather than from a locally cached dashboard.

Stamp an address before using it

  1. Create or import an ML-DSA-87 account in the wallet. Legacy ECDSA accounts must migrate before they can use post-quantum private flows.
  2. Open Stamp address (or the console wallet's stamp flow) and enter the name and country you want committed to the address.
  3. Review the registration transaction. It is a zero-value protocol transaction to the reserved Shielded Pool address and is verified by consensus.
  4. Wait for confirmation, then check the address status in the wallet or explorer. Do not delete the stamp key: it is the only way to reveal the label later.

An address with no confirmed stamp cannot send a value transfer or a Shield3/Shield4 withdrawal after Antartical. A recipient must also be stamped. Stamps are immutable registrations; choose the label carefully.

Release v1.21.62 adds a read-only address display to the guided terminal wallet. Start a node, then run:

./build/bin/gtkm wallet interactive

Choose 11) Show Shield3 address, select the stamped ML-DSA-87 account, and enter that account's PQ password. The wallet derives and prints the public tkmshield3.… receiving code. Share that code with the payer; it is the authenticated Shield3 payment address and is different from the ordinary 0x… ML-DSA account address shown under Accounts.

The operation does not send a transaction, change the stamp, or expose a seed, private viewing key, or plaintext name/country. If the account is not an ML-DSA-87 account or its stamp is missing or unconfirmed, the wallet stops with an actionable error. Use 7) Stamp address first, wait for its confirmation, and then return to 11) Show Shield3 address.

Register a Rotating King

Rotating Kings are funded accounts selected by the consensus rotation schedule. To register from a local node, run ./gtkm wallet interactive, choose Kings, press r, select the account, review the requirement, and type REGISTER. The wallet calls rk_add over local IPC and displays a chain-bound registration hash after the request succeeds.

Press s to inspect a registration by account number or address. The Kings screen automatically lists registrations and recent rotation history. The status view shows the stake, registration hash, added height, unlock height, and current/next role. The same state can be checked with rk_status, rk_list, and rk_getKingStats.

The minimum is 50,000 TKM before Antartical and 100,000 TKM from Antartical activation, plus the 1-TKM registration fee reserve. Egypt uses the post-fork rule from genesis. Registration does not move funds outside a block; spending below the active requirement makes the account ineligible and consensus removes it from the rotation schedule.

Back up a post-quantum account

When an ECDSA account is migrated in the console wallet, the new ML-DSA-87 seed is shown only after the migration receipt is canonical. The wallet displays the exact seed as a standard English BIP39 recovery phrase of 24 words instead of raw hexadecimal. Write the words down in order and keep them separate from the account password. ethkey inspect --private uses the same representation, and ethkey generate --pqseed accepts the phrase when restoring a key.

Transfer TKM privately

  1. Confirm that the sender and recipient both show a confirmed stamp.
  2. Select Shield3 or Shield4 in the wallet and choose the recipient's private payment key. Shield4 is intended for the newer multi-input and link-tag flow.
  3. Choose the asset and amount, review the fee and the 5,000,000 TKM aggregate send limit, and create the proof locally. Never paste an owner secret into a relay or web form.
  4. Submit the signed bytes through the wallet's onion relay or your local node. A relay can forward a transaction but cannot open notes or change its recipient, amount, nonce, or proof context.
  5. Keep the transaction hash for delivery tracking. Use the incoming viewing key to scan received notes, the outgoing viewing key to disclose payments you made, and a disclosure capsule when an auditor or bank needs one payment record.

Transparent EVM/TVM transfers are disabled after Antartical. A transaction that is not a valid post-quantum private envelope, stamp registration, or other consensus protocol envelope is rejected by both the mempool and block execution.

Vote on a suspicious address

Address voting is a consensus-governed, public investigation signal. It is not proof that a theft occurred, and it does not give voters access to funds.

gtkm governance vote --from 0xYOUR_STAMPED_ADDRESS --address 0xTARGET --reason fraud
gtkm governance unvote --from 0xYOUR_STAMPED_ADDRESS --address 0xTARGET
gtkm governance status --address 0xTARGET

The command signs a post-quantum protocol transaction locally. The voter must have a confirmed stamp. Each stamp owner can cast one vote for a target, even if that owner controls several addresses. The reason is bounded and recorded in the signed transaction for public review. Fifteen distinct active stamp owners suspend the target from sending and spending. A voter can remove only its own vote; when the count falls below fifteen, the suspension marker clears. Every vote and unvote burns 50 TKM from the stamped voter; the transaction value remains zero and the amount is destroyed by consensus. The voter must fund gas and the burn separately. Existing canonical history is never rewritten.

Investigators should publish evidence, allow the address owner to respond, and ask voters to unvote after a clean review. Operators can query tkmgov_getAddressVoteStatus to see the active count, threshold, and suspension marker at the canonical head.

Run a node through Tor

Install Tor for your operating system, create an onion service for the P2P port, and start gtkm with onion-only networking. Keep HTTP and WebSocket RPC on 127.0.0.1; applications such as the wallet, explorer, and pool should reach them locally or through an authenticated onion reverse proxy.

./gtkm --privacy.onion-only \
  --p2p.tor-socks5=socks5://127.0.0.1:9050 \
  --p2p.onion-hostname=YOUR_NODE.onion \
  --bootnodes='enode://NODE_ID@PEER.onion:3000?discport=0' \
  --http --http.addr=127.0.0.1 --http.port=8545 \
  --ws --ws.addr=127.0.0.1 --ws.port=8546

Check the startup line for an onion hostname rather than 127.0.0.1, and check the peer count after the node has had time to establish circuits. If the node data directory is already in use, stop the existing gtkm process before starting another one.

Mine with XMRig

Use the XMRig release that matches your CPU and point it at the onion pool endpoint. Copy the TKM algorithm, wallet address, and worker name into config.json; do not put a private seed in the miner configuration.

{
  "autosave": true,
  "pools": [{
    "url": "YOUR_POOL.onion:33330",
    "user": "YOUR_STAMPED_PQ_ADDRESS",
    "pass": "worker-1",
    "coin": "TKM",
    "daemon": false,
    "tls": true
  }]
}

The pool difficulty is a share target, not a promise of a block. A rejected share should include the pool's verification reason; RandomX hash mismatch means the pool and miner disagree about the job and must be fixed before mining continues.

Wallet, Phone, and EmailVM

The interactive wallet connects to the local IPC endpoint and signs locally. It can show stamped identities, buy an available phone number, register a PQ device, send encrypted messages, inspect an address vote status, and migrate an ECDSA account to ML-DSA-87. Android first establishes a Tor connection, then starts the embedded node; if bootstrap installation replaces data, restart only after the app requests it.

Phone numbers and mailboxes are address-owned records. A lookup can show whether an address has a number or mailbox without requiring the user to know the number first. Message bodies and device keys are encrypted; availability, ownership, and protocol state remain verifiable chain data.

Operator checklist