Conflux (CFX)

Conflux (CFX): How Its Tree-Graph Network, Dual Spaces and DAO Fit Together

Conflux is a smart-contract network that combines a Tree-Graph ledger with hybrid proof-of-work and proof-of-stake consensus. Its CFX token pays for network activity, supports staking and governance, and remains subject to protocol-controlled issuance and burns.

What Conflux is built to do

Conflux is a public smart-contract platform with two execution environments: Core Space, the network’s native environment, and eSpace, an Ethereum-compatible environment running over the same underlying network. Core Space uses Conflux-specific address and transaction formats, while eSpace is designed to support Ethereum tools, wallets, Solidity contracts and development workflows. The split gives developers a choice between Conflux-native features and a more familiar EVM experience, but it also means that users must understand which space holds an asset or contract before interacting with it.

The intended users are therefore broader than CFX holders alone. Developers can deploy smart contracts, applications can use sponsored execution, and network participants can mine, stake or operate infrastructure. The official code repository identifies conflux-rust as the Rust implementation of the protocol and directs developers to the Conflux documentation for installation and node operation. That makes the client software and associated toolchain practical dependencies for anyone assessing the network’s continued operation and upgrade capacity.

Tree-Graph consensus and finality

Conflux does not treat every block outside a single longest chain as wasted. Its Tree-Graph structure allows blocks to contain both a parent relationship and references to earlier blocks. The GHAST chain-selection rule then chooses a pivot chain using the mining power supporting a subtree, after which the protocol orders transactions using the pivot and reference edges. The design is intended to use concurrent block production while still producing an executable ledger order.

The live documentation describes consensus as hybrid: proof-of-work miners produce and order blocks, while proof-of-stake participants sign pivot blocks to provide finality and reduce the probability of reversals. CFX therefore has a direct security role beyond paying fees. It is used in the staking system that selects or supports proof-of-stake participants, while mining remains a separate source of network security and token issuance. This division also creates two distinct dependency sets: the network needs sufficient hash power for its PoW layer and sufficient, properly functioning stake participation for finality.

What CFX does inside the network

CFX is the native unit used for transaction fees and other network-level payments. In Core Space, it can also be deposited into the built-in staking contract. The documentation states that staking records balances for both ordinary accounts and smart contracts, with deposits and withdrawals handled by internal contract functions. Locked staking balances can be used to obtain governance voting power, although the lock creates a withdrawal restriction until the relevant block height.

A notable application-level feature is contract sponsorship. A contract operator can fund gas and storage costs so that an eligible user may interact without holding CFX for each transaction. Sponsorship applies to contract calls rather than ordinary CFX transfers, and administrators can restrict the benefit through a whitelist. This can reduce the initial wallet-funding burden for dApp users, but it makes the user experience dependent on the sponsor’s balance, configured spending limits, whitelist rules and contract administration.

Core Space, eSpace and practical dependencies

Core Space and eSpace share underlying ledger data but maintain logically separate account states, contracts and transaction views. A built-in CrossSpaceCall mechanism is used for selected interactions between them, including CFX transfers and cross-space contract calls. Developers choosing Core Space gain access to native features such as sponsorship, but must use Conflux-compatible addresses, RPC interfaces and SDKs. Developers choosing eSpace can use Ethereum-oriented tools, but still need to account for the network’s own execution and transaction-packing rules.

This architecture creates a practical operational risk for newcomers: an address format, wallet or contract interface that is correct for one space may not be correct for the other. The documentation specifically distinguishes Conflux base32 addresses in Core Space from Ethereum-style tooling in eSpace. Asset custody, bridge or cross-space transfer design, RPC selection and contract verification are therefore not peripheral details; they are part of using the network correctly.

Issuance, burns and governance control

CFX does not have a fixed maximum supply in the project’s published economic model. New tokens are issued through proof-of-work block rewards and proof-of-stake interest, while some activity can remove CFX through base-fee burns and storage-related conversion. The published documentation also records an initial five-billion-token allocation across private funders, foundation holdings, the genesis team, community funding and ecosystem funding. Its historical parameter examples are explicitly snapshots, so they should not be treated as current issuance or inflation figures without checking live governance parameters.

The governance model gives locked CFX voting weight based on both the amount locked and the duration. The documentation describes voting rights of 0.25 vote per CFX after one quarter, 0.5 after more than half a year and 1 vote after more than a year, with locked tokens remaining unavailable for withdrawal during the commitment. DAO-controlled parameters include the PoW base reward, PoS interest rate, storage conversion proportion and the share of base fees burned or paid to miners. Governance therefore affects both network operation and the token’s future supply path, while voting power is tied to capital and lock duration.

What remains uncertain

The architecture provides identifiable mechanisms, but those mechanisms do not by themselves establish broad application adoption, durable fee demand or decentralisation in practice. The official sources describe the protocol, tools and intended incentives; they do not provide a complete independent assessment of user activity, validator concentration, mining concentration, contract security or the commercial durability of applications built on the network. Those questions require separate, time-sensitive analysis of on-chain data, infrastructure participation and deployed contracts.

Key takeaways

• Conflux combines a Tree-Graph ledger and GHAST ordering with proof-of-work block production and proof-of-stake finality.
• CFX is used for fees, staking, governance locks and network incentives rather than serving only as a transferable asset.
• Core Space offers native Conflux features such as contract sponsorship, while eSpace targets Ethereum-compatible development and tooling.
• Contract sponsorship can remove some up-front gas and storage friction, but it depends on sponsor balances, limits and whitelist settings.
• CFX supply is adjustable: issuance comes from mining and staking, while some fees and storage-related amounts can be burned.
• DAO governance controls several monetary and network parameters, and voting power increases with both locked CFX and lock duration.

Risks and open questions

• The token supply is not fixed, and issuance and burn parameters can change through governance decisions.
• Hybrid consensus creates dependencies on both proof-of-work hash power and proof-of-stake participation; concentration in either layer could affect resilience.
• Core Space and eSpace use different account, tooling and execution conventions, creating operational risks for custody, contract interaction and cross-space transfers.
• Contract sponsorship is not universal: it applies to eligible contract interactions and can fail when balances, limits or whitelist settings are insufficient.
• The published economic documentation includes historical parameter snapshots that may no longer represent current issuance, staking returns or inflation.
• The reviewed primary sources do not independently establish the level, concentration or durability of real-world application adoption.