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 | Scheduled |
| Mainnet | To be determined (based on the Testnet results) | In preparation |
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.
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. 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 |
The distribution URL for these files will be announced on this page once confirmed.
Step 2 — Update Geth to v1.16.8
The version currently documented on this site ("tested up to Geth version 1.13.5") cannot follow the chain after the hardfork.
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 |
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.