Skip to main content

Architecture

ZENIQ Smart Chain is EVM-compatible on the surface, but under the hood it is not a go-ethereum clone. It is a fork of smartBCH and pairs a Tendermint consensus engine with a parallel EVM execution engine. This page explains the parts that surprise developers coming from Ethereum.

Consensus and execution are separate engines​

  • Consensus engine — Tendermint. It proposes blocks and votes on them. Finality is fast and deterministic: once a block is committed there are no reorgs and no uncles (which is why eth_getUncle* always returns empty).
  • Execution engine. It takes committed blocks from Tendermint, updates the world state, and produces transaction receipts and logs. It is the part that runs the EVM.

The two engines run concurrently. While the execution engine is finishing the current block, Tendermint is already collecting votes and proposing the next one. This overlap is a big part of how the chain sustains throughput.

Blocks are ~4 seconds and gas is legacy​

  • Block time is about 4 seconds.
  • The fee model is legacy — a single gasPrice, not EIP-1559. There is no baseFee or priority fee. Read the price with eth_gasPrice.
  • The EVM targets the London instruction set; the Shanghai PUSH0 opcode is not supported, so compile with Solidity 0.8.19.

State is split into three stores​

Unlike a single Ethereum state trie, ZENIQ Smart Chain keeps three independent stores with different roles:

  1. Authenticated world state (ADS). A Merkleized key/value store that holds accounts, balances, contract code and storage. Its root hash is the block's app hash — this is the consensus-critical state.
  2. History / query database. A queryable index of blocks, transactions and logs. It powers eth_getLogs and the richer zeniq_* query methods. It is not consensus-critical and can be rebuilt.
  3. Cross-chain FIFO. A small store used by the cross-chain importer (below).

Transactions are executed after commit — in parallel​

This is the biggest departure from Ethereum. When a block is committed, its transactions are not executed one-by-one in order. Instead:

  1. During the commit phase, transactions are validated (signature, sender, gas) and placed into a standby queue that lives inside the world state. The app hash is computed and returned to Tendermint.
  2. During the post-commit phase, transactions are pulled from the standby queue and executed in parallel across multiple goroutines, with a dependency check that commits only non-conflicting transactions and re-queues the rest.

See Parallel execution for the full flow.

To keep parallel execution deterministic — and to blunt front-running — transactions are also pseudo-randomly reordered before execution, using a seed derived from the block itself. See Transaction ordering.

Cross-chain importer (CCRPC)​

ZENIQ Smart Chain is a sidechain of the ZENIQ main chain. A built-in cross-chain importer mirrors value from the legacy ZENIQ main chain onto the Smart Chain. You can inspect the imported transfers with zeniq_crosschainInfo — a method that has no smartBCH or Ethereum equivalent.

What this means for developers​

For the vast majority of contracts and tooling, none of this is visible — you deploy Solidity and call it over standard JSON-RPC. The practical takeaways:

  • Don't rely on the proposer's transaction order; it is reordered on-chain.
  • Don't design around uncles, reorgs, or EIP-1559 fee fields — they don't exist.
  • For deep transaction tracing and wide historical queries, prefer the zeniq_* methods over their thinner eth_* counterparts.