Japan Open Chain sets November 27 consensus migration

Japan Open Chain has scheduled the first mainnet phase of its Tokyo Hard Fork for around noon Japan Standard Time on November 27, setting a defined migration point for the network’s consensus system. The November 13 announcement moves the project from an open-ended roadmap to an operational deadline, but the upgrade has not happened yet and its exact activation time remains variable.

The network plans to replace its existing Clique proof-of-authority block-production system with what it calls proof of staked authority, using a separate beacon chain and an execution-consensus split modeled on Ethereum’s post-Merge architecture. The change is material for node operators because a standalone execution client will no longer be enough to follow the canonical chain.

The trigger is difficulty, not the clock

Japan Blockchain Foundation, which operates the consortium behind the network, set terminal total difficulty at 47,370,500. The merge should occur at the first block reaching that threshold, so November 27 is an estimate rather than a guaranteed timestamp. The project’s mainnet repository independently publishes the same threshold in its execution and consensus configuration and says automated checks are intended to catch a mismatch.

The foundation said the mainnet beacon chain began operating on September 18 after a September 7 testnet migration. Its public repository records beacon-chain genesis at 11:44:51 UTC on September 18 and says the chain is finalizing with eight active validators. Those observations establish that the new consensus layer is running in parallel; they do not establish that the execution layer has already migrated.

During the mainnet transition, external access to both the old and new chains is expected to be restricted for about 30 minutes before and after the merge—roughly one hour in total. The operator says block production will continue while transaction processing is suspended. Both the timing and duration are plans that may change with network conditions.

Node operators face the main operational burden

Ordinary holders and users of project-provided RPC endpoints are not expected to take action. Existing accounts, balances, contracts, transaction history and chain ID 81 are supposed to remain in place.

Organizations running their own nodes must instead pair Geth with a consensus client such as Lighthouse and connect them through the authenticated Engine API. The project’s current instructions specify Geth 1.13.5 and Lighthouse 7.0.1 as tested versions, while warning that Geth 1.14.0 or later cannot currently sync the chain. A node that misses the configuration change may remain on the discontinued branch and return stale blocks or transaction data.

That limitation narrows the meaning of “Ethereum compatibility.” Japan Open Chain already supports the Ethereum Virtual Machine, and the new architecture is intended to bring its consensus layout closer to Ethereum’s. It is not joining Ethereum, inheriting Ethereum’s validator set or becoming secured by ether staking.

What the announcement does not prove

The November 13 record establishes a schedule, configuration and migration procedure. It does not demonstrate a successful mainnet fork, uninterrupted transaction resumption or broader use of the network. The foundation also describes the change as strengthening governance by moving validator registration, management and staking onchain, but the initial beacon-chain record still shows only eight active validators.

Later Tokyo phases are intended to add features associated with Ethereum’s Shapella, Dencun and Pectra upgrades. No activation dates for those phases were established in the reviewed materials, and the November 27 event should not be described as delivering them.

The next verifiable milestones are the terminal-difficulty trigger, confirmation that execution follows the beacon chain, the end of the planned access restriction and evidence that independent nodes remain synchronized. Until those checks are available, the development is a scheduled consensus migration rather than a completed upgrade.