Conflux has scheduled the v3.1.0 hard fork for August 25 and requires node operators to complete the upgrade before the network reaches the target epoch. This update will activate seven network proposals, focusing on enhancing compatibility with the Ethereum ecosystem while resolving existing issues with transactions, staking, and cross-space calls.
Nodes must be upgraded by August 25.
In its early August announcement, Conflux stated that all nodes must upgrade to v3.1.0 before the blockchain reaches epoch 155140000, currently expected around August 25. Since block generation speed affects the actual trigger time, the project team has set epoch 155140000 as the official threshold rather than a fixed calendar date.
If the node completes the upgrade before the deadline, the operator only needs to install the new version and restart the system. Conflux recommends completing the entire process within two days after starting the upgrade. If the target epoch is missed, the node will need to clear existing chain data, reinstall the latest version, and redownload the network history.
The project team also warns that continuing to use the old software version will result in incomplete compatibility with the upgraded chain; related nodes may fail to sync new blocks, process transactions, or continue mining. This update also requires replacing critical configuration files, as old configurations will no longer be able to start nodes under stricter validation.
Seven proposals take effect simultaneously.
This hard fork is planned to activate CIP-166, 167, 172, 173, 174, 175, and 176. Of particular interest are the changes related to eSpace. Conflux states that three proposals will align eSpace more closely with recent Ethereum standards, facilitating compatibility with Ethereum-based smart contracts, wallets, and development tools.
CIP-166 introduces new opcodes to maintain alignment with Ethereum's new standards; CIP-167 adds direct support for a type of digital signature adopted by WebAuthn and passkey login systems; CIP-174 limits the data size that can be submitted by computationally intensive functions and increases associated transaction fees to reduce excessive network resource consumption from overly large requests.
Conflux's recent emphasis on eSpace is also related to the supported range of trading platforms. Previously, the Korean exchange Upbit restricted CFX deposits and withdrawals to Conflux eSpace only, advising users that asset recovery processes may be lengthy if funds are transferred via Core Space or other unsupported networks.
Fixed trading and staking issues
In addition to compatibility upgrades, the other four proposals primarily address issues in the current network behavior. CIP-172 requires all transactions written to blocks to use a standardized format. Conflux states that existing issues may cause the same transaction to have multiple identifiers, and on-chain services typically rely on these identifiers to locate and verify transfers.
CIP-173 addresses issues in the proof-of-stake validator dispute resolution process and extends the existing CFX staking lock-up mechanism to validators who have initiated the full withdrawal of their stake. As projected by the project team, this proposal will take effect at PoS block 3749400 on August 26.
CIP-175 fixes permission recognition issues for certain calls between Core Space and eSpace; CIP-176 corrects the preparation of access list data before transaction execution to ensure all entries for the same account are processed, not just the last one.
Security patch details will not be disclosed at this time.
Conflux stated that the security patch details are not being disclosed publicly to prevent attackers from exploiting the information before all nodes have upgraded. The project team will disclose the affected software components only after the hard fork is completed and nodes have had sufficient time to migrate to the protected version.
Additional information: Conflux noted that in March 2025, a similar vulnerability in contract deployment was patched. After the ecosystem team GraFun privately reported the issue, the project team resolved it in v2.5 and awarded them 60,000 CFX as a reward.

