Tokyo Hardfork (Japan Open Chain v2)

Japan Open Chain will carry out a network upgrade called the Tokyo Hardfork. With this hardfork, the consensus mechanism migrates from Clique PoA to PoSA (Proof of Staked Authority / PoA v2).

Schedule

Network	Date	Status
Testnet	September 7, 2026	Completed
Mainnet (beacon chain launch)	September 18, 2026	Completed
Mainnet (Phase 1 / The Merge)	To be determined (decided at the validator meeting)	In preparation

For node operators

If you operate a node on Testnet, please complete the configuration change before September 7, 2026. Upgrading Geth alone is not sufficient. See the steps below for details.

About the Mainnet beacon chain

The Mainnet upgrade proceeds in two stages.

Beacon chain launch (September 18, 2026 — completed)
The Consensus Layer started running ahead of the Execution Layer. Blocks are still produced by Clique PoA, so there is no impact on general users or node operators at this time.
Phase 1 — Hardfork (The Merge) (to be determined)
The Execution Layer will start operating under instructions from the beacon chain. Organizations running their own node will need to change their configuration at this point. The date will be announced on this page once it is decided at the validator meeting.

The Mainnet configuration files (config.yaml, genesis.ssz, deposit contract information, and the bootnode / boot ENR lists) are published under the metadata/ directory of the japan-open-chain/mainnet repository. For the detailed node setup steps, see the Mainnet node connection guide.

What you need to do at this stage

Who you are	Required action
JOC holders, general users, and users of the JOC RPC endpoints	No action required
Organizations running their own node on Mainnet	Keeping your current Execution Client (Geth)–only setup is fine, but we recommend setting up a Consensus Client (recommended: Lighthouse) now, ahead of the next hardfork (The Merge), by following the Mainnet node connection guide

For Mainnet node operators

Before the hardfork, Geth v1.14.0 or later cannot sync the chain. Please continue using the v1.13 series.

What you need to do

Who you are	Required action
JOC holders and general users	No action required
Users of the JOC RPC endpoints	No action required
dApp developers	The Chain ID does not change. Action is required only if you run your own node
Organizations running their own node	Action required at the hardfork. Follow the steps below to change your node configuration
Validators	Action required. Separate instructions will be provided

Steps for Testnet node operators

Who this applies to: organizations that sync directly from the JOC Testnet boot nodes and operate their own node. If you use the JOC RPC endpoints, no action is required.

Upgrading Geth alone is not sufficient

Under PoA, the Execution Client (Geth) verified and synced blocks on its own. After the migration to PoSA, block validity is determined by the Consensus Layer (the beacon chain). Geth handles execution only, and receives fork choice instructions from the Consensus Client.

The work required is therefore a configuration change, not a version upgrade.

[Current]                    [After the Tokyo Hardfork]

 Geth (standalone)            Geth ── Engine API ── Lighthouse
   │                            │                      │
 P2P to                     execution only     consensus / fork choice
 boot nodes                                              │
                                                  to CL boot nodes

1. Complete before the hardfork

Step 1 — Obtain the configuration files

File	Purpose	Notes
`genesis.json` (updated)	For the Execution Client. Contains the TTD and each fork time	Different from the currently published version
`config.yaml`	Chain specification for the Consensus Client	Defines fork epochs and the network ID
`deposit_contract_block.txt`	Block number of the Deposit Contract
`genesis.ssz`	Beacon chain genesis state	Approx. 5.5 MB

note

The distribution URL for these files will be announced on this page once confirmed.

Step 2 — Keep Geth on the v1.13 series

Continue to use Geth v1.13.5, the version verified on this site. Geth v1.14.0 and later cannot currently sync the chain.

note

A newer version of Geth will be required for the Shapella, Dencun, and Pectra phases. We will announce the supported version on this page once the schedule is confirmed.

Step 3 — Set up a Consensus Client

Recommended: Lighthouse v7.0.1 (Docker image sigp/lighthouse:v7.0.1)
Prysm is not recommended: our internal testing found connection errors and sync issues from the Shapella phase onward
It can run on the same host as your existing Geth
Boot nodes (ENR) for the Consensus Layer must be configured (to be announced once confirmed)
We recommend checkpoint sync for the initial sync (the endpoint will be announced once confirmed)

Step 4 — Connect Geth and the Consensus Client over the Engine API

The two communicate over the authenticated Engine API (default port 8551). Generate a shared JWT secret and configure it on both sides.

# Example: generating the JWT secret
openssl rand -hex 32 | tr -d "\n" > /data/jwt.hex

Startup options to add on the Geth side:

--authrpc.addr=127.0.0.1
--authrpc.port=8551
--authrpc.jwtsecret=/data/jwt.hex
--authrpc.vhosts=localhost

Step 5 — Verify sync and connectivity

The Consensus Client has caught up with the beacon chain
Geth's log records fork choice updates over the Engine API
Keep both clients running on the day of the hardfork. The Merge fires automatically when the configured TTD is reached

2. Work required at each phase after the hardfork

For the Shapella, Dencun, and Pectra phases, you will need to update your configuration and restart after our announcement.

Phase	Execution Client	Consensus Client
Phase 2 — Shapella	Set `shanghaiTime`	`CAPELLA_FORK_VERSION` / `CAPELLA_FORK_EPOCH`
Phase 3 — Dencun	Set `cancunTime`	`DENEB_FORK_VERSION` / `DENEB_FORK_EPOCH`
Phase 4 — Pectra	Set `pragueTime`	`ELECTRA_FORK_VERSION` / `ELECTRA_FORK_EPOCH`

warning

Do not update your configuration or restart at your own discretion before our announcement.

3. If you do not take action

After the hardfork, the node will no longer receive new blocks and will not be able to follow the head of the chain
Applications and wallets connected to that node over RPC will not be able to retrieve the latest blocks or transactions
A node left behind on the old chain may keep returning data from the discontinued chain
Note that ordinary nodes are never slashed (only validators are subject to slashing)

4. Frequently asked questions

Q. Do I need to register as a validator or deposit 32 JOC?

No. Ordinary nodes that do not produce blocks require neither Launchpad registration nor deposit data. Only the configuration change described above is needed.

Q. Do I need to delete my existing chain data and resync?

No. All existing chain data and transaction history are preserved.

Q. Does the Chain ID change?

No.

Q. Do I need an additional server?

The Consensus Client can run on your existing host, provided it has sufficient disk and memory headroom.

Contact

For questions about this hardfork, please reach out via the contact form.

Schedule​

About the Mainnet beacon chain​

What you need to do at this stage​

What you need to do​

Steps for Testnet node operators​

Upgrading Geth alone is not sufficient​

1. Complete before the hardfork​

Step 1 — Obtain the configuration files​

Step 2 — Keep Geth on the v1.13 series​

Step 3 — Set up a Consensus Client​

Step 4 — Connect Geth and the Consensus Client over the Engine API​

Step 5 — Verify sync and connectivity​

2. Work required at each phase after the hardfork​

3. If you do not take action​

4. Frequently asked questions​

Contact​