Neura for Developers

Chain Identity and Performance

Chain Classification

Neura is a high-performance Layer 1 blockchain built using the Hyperledger Besu client and running a QBFT (Quorum Byzantine Fault Tolerance) consensus mechanism. This architecture provides full EVM compatibility with deterministic, instant finality — making it ideal for real-time AI and DeFi applications.

Neura diverges from Ethereum's Beacon Chain-based PoS consensus by using QBFT. The table below outlines key differences in chain design and validator mechanics:

Feature	Ethereum (Beacon Chain PoS)	Neura (Besu & QBFT)
Consensus Algorithm	Gasper (LMD-GHOST + Casper FFG)	QBFT (Byzantine Fault Tolerant)
Validator Set	Open, permissionless staking (32 ETH), subject to queues; very large dynamic set.	Permissioned; validators are explicitly defined in a configuration; a smaller, known set.
Block Proposers	Randomly selected from the active validator set for each slot.	Round-robin selection among the current validator set.
Finality	Probabilistic for individual blocks. Epochs get "justified" (~6.4 min) and then "finalized" (~12.8 min). Reorgs possible before finality.	Immediate and deterministic — no forks or reorgs, so all nodes process and commit transactions in the same order, achieving identical state immediately
Network Type	Public, global, permissionless.	Public access with permissioned validators.
Block Structure & Headers	PoS-specific fields: slot, proposer_index, parent_root, state_root, body_root, and attestations. The DIFFICULTY opcode was replaced by PREVRANDAO (Beacon Chain pseudo-randomness).	QBFT-specific fields: validator signatures, round number, and commit seals used to finalize blocks.
EVM Compatibility (Core)	Native EVM support.	Native EVM via Besu client.
Blob Support (EIP-4844)	Supported post-Dencun.	Not supported.
Throughput & Latency	Lower throughput, higher latency due to global scale and PoS mechanics.	Higher throughput and lower latency due to smaller validator sets and faster block finality (BFT).

Key Differences Summarized for EVM Context:

• Finality: Transactions on Neura are final once included in a block — no reorgs or confirmation windows required.

• PREVRANDAO: Not supported — smart contracts relying on Ethereum's randomness opcode will behave differently.

• Validator Interaction: Neura validators are permissioned; staking-based protocols from Ethereum will not apply directly.

• Blob Support: Currently unsupported; blob-enabled rollups or contracts relying on EIP-4844 features must adapt.

While the core EVM execution (opcodes, smart contract logic) is highly compatible because Besu is an Ethereum client, the environment around the EVM (consensus, finality, fee market details, validator interactions, and advanced features like blobs) are distinct when using QBFT.

Performance Characteristics

Block Time	2 seconds
Finality	Immediate (no probabilistic delay)
Theoretical TPS	~16,666 TPS (based on 700M gas/block and 2s block time)
Practical TPS	TBD – subject to load testing under real-world conditions

The theoretical throughput assumes 700 million gas per block with an intrinsic gas cost of 21k per transaction. However, actual TPS will depend on smart contract complexity and node capacity.

EVM Fork Compatibility

Neura supports the Cancun-Deneb (Dencun) fork, including most recent Ethereum features. Some features from the upcoming Prague/Electra fork are also already supported, with full compatibility planned in future upgrades.

Address Format and Cryptography

• Address Format: 20-byte Ethereum-style addresses (Keccak-256 of ECDSA public key)

• Signature Scheme: ECDSA, same as Ethereum

Key Architecture Components

This section outlines the foundational technical components that power the Neura blockchain. From consensus mechanisms and execution models to bridging infrastructure and treasury control, each component plays a critical role in ensuring Neura’s security, scalability, and interoperability. While Neura retains full EVM compatibility, its architecture integrates tailored innovations for validator coordination, deterministic finality, and multi-chain asset flows.

QBFT-based Consensus	QBFT (Quorum Byzantine Fault Tolerance) is inherently designed for fast finality. Blocks are proposed by a validator, and once a supermajority of other validators sign off on it, the block is considered final. This makes it "fork-resistant" because once a block is finalized, it cannot be reverted, preventing chain splits that can occur in probabilistic consensus mechanisms like Proof-of-Work. Neura leverages this for quick and deterministic transaction settlement.
Block Propagation Layer	Hyperledger Besu uses a P2P gossip protocol for block and transaction propagation.
Execution Model	Neura executes transactions sequentially, following the traditional EVM model. Validators finalize the block order through QBFT consensus, then execute transactions in that block one-by-one. While execution follows immediately after consensus without delay, the model is formally asynchronous — consensus and execution are decoupled but not pipelined.
State Storage / Access Layer	Besu, like other Ethereum clients, uses a modified Merkle Patricia Trie to store world state, which allows for verifiable proofs. Updates involve creating new trie nodes.
Safe Multisig & Tx Aggregator	The SafeTxnAggregator is an on-chain coordination service that collects and aggregates validator signatures for Safe multisig transactions. It acts as the intermediary between validator add-ons and the Safe multisig. Once a threshold of validator signatures is reached, the aggregator submits the transaction to the Safe multisig for execution.
Validator Add-on	A helper module attached to each Neura validator’s Besu node. It observes bridge-related events, processes bridge messages, signs them using the validator’s key, and submits signatures to the appropriate destination (SafeTxnAggregator or Neura Bridge contract). Enables validator participation in cross-chain bridge operations.
Bridging System	Each validator add-on is responsible for monitoring events, signing bridge messages, and ensuring they are relayed correctly for either multisig execution (inbound transfers) or validator approval (outbound transfers).
Neura Vault	The central holding contract for all ANKR tokens on the Neura chain. It is controlled by the Safe multisig and is used to distribute pre-minted ANKR based on validated bridge transactions. Transfers from the Vault are executed only via the Safe multisig once validator signatures have been aggregated and approved through the SafeTxnAggregator.

Transactions

Neura follows Ethereum’s transaction model, supporting multiple EVM-compatible types and EIP-1559 gas pricing. This section outlines how transactions are formatted, prioritized, and executed within the network.

Address Space	Neura uses standard 20-byte Ethereum-style addresses based on the ECDSA (secp256k1) signature scheme.
Transaction Format / Types	Neura supports Ethereum transaction types including Legacy (Type 0), EIP-2930 (Access List), EIP-1559 (Dynamic Fee), and EIP-7702 (Smart Accounts).
Wallet Compatibility	Compatible with standard Ethereum wallets such as MetaMask via Neura’s JSON-RPC APIs.
Gas Pricing	Neura uses EIP-1559 gas pricing with a base fee and priority tip. Transactions are prioritized using the default Besu mempool selector (likely total gas price).
Gas Fee Behavior	Gas is charged based on actual usage, not the gas limit. No DoS-specific gas logic beyond EIP-1559 behavior.
Testnet vs Mainnet	No differences expected between testnet and mainnet behavior.

Smart Contracts

Neura supports standard Ethereum smart contracts with full EVM compatibility. Developers can deploy contracts without modification, relying on familiar opcode behavior, gas costs, and size constraints.

Opcodes	Neura is bytecode-equivalent to Ethereum and supports all EVM opcodes up to the Cancun fork. No opcodes have been modified, added, or removed.
Opcode Pricing	Neura uses Ethereum’s opcode gas cost model with no Neura-specific differences or optimizations.
Max Contract Size	Neura enforces the same smart contract bytecode size limit as Ethereum — 24 KB.

Consensus

Neura achieves fast and deterministic block finality through the QBFT (Quorum Byzantine Fault Tolerance) consensus mechanism, a leader-based protocol optimized for permissioned networks. Unlike probabilistic consensus used in public PoS chains, QBFT finalizes blocks immediately once a supermajority of validators reach agreement, eliminating forks and reorgs. This chapter outlines how Neura selects validators, propagates blocks, separates consensus from execution, and ensures consistent state transitions across all nodes.

Sybil Resistance Mechanism	Permissioned validators
Delegation	Planned for the future; not yet implemented.
Consensus Mechanism and Pipelining	QBFT, as implemented in clients like Hyperledger Besu, is typically designed to be pipelined with execution: Consensus (QBFT) finalizes block N. This finalized block N (an ordered list of transactions) is handed off to the EVM for execution. Simultaneously, the QBFT consensus mechanism can start the process for block N+1 (e.g., validators can start proposing the next block, gathering transactions for it, and entering the initial QBFT rounds for block N+1).
Block Propagation Mechanism	Standard Ethereum P2P gossip protocol as used in Hyperledger Besu.
Block Frequency	Currently 2s; future targets include 1s or sub-second block times.
Finality	A block achieves deterministic and immediate finality once COMMIT messages are received from a majority of validators. No further confirmations needed. This makes the chain fork-resistant at the point of finality.
Mempool	Each Neura node (validators and non-validators) maintains its own local mempool. Transactions are shared across the network using Ethereum’s standard P2P gossip protocol. When it’s a validator’s turn to propose a block, it selects transactions from its local mempool.
Consensus Participants	A list of permissioned validators is configured at network launch.
Asynchronous Execution	Consensus on transaction ordering is established independently before execution. Execution follows immediately after consensus, but the two processes are logically decoupled. The state root for block N is determined immediately after all transactions in block N have been executed. Overspending and spam are mitigated through EIP-1559-style dynamic gas pricing, which increases costs during congestion.
State Determinism	Execution on Neura is fully deterministic after consensus. The Ethereum Virtual Machine (EVM) ensures that given the same transaction sequence and initial state, all nodes will compute the same resulting state. Neura's QBFT consensus guarantees agreement on that transaction sequence, so all compliant full nodes process the same inputs in the same order — ensuring consistent and verifiable state transitions across the network.

Execution

This section outlines how Neura handles transaction execution, covering ordering, concurrency, validation, and determinism.

Transaction Ordering

Neura uses the QBFT consensus mechanism to determine the exact order of transactions within each block. All validators agree on this sequence before execution begins. The transaction order finalized by QBFT is strictly preserved during execution, ensuring determinism across the network.

Execution Model

Neura executes transactions sequentially, following the traditional Ethereum Virtual Machine (EVM) model. Validators execute transactions one-by-one during block construction, in the exact order they appear in the block. This tightly couples consensus and execution phases and simplifies state management.

Execution Result Validation

Before including a transaction in a block, the block proposer checks that:

• The nonce is contiguous with the sender's last confirmed transaction.

• The account balance is sufficient to cover gas_limit × gas_price + value.

Once consensus on a block is reached, these transactions are executed exactly as finalized. If a transaction fails during execution (e.g., due to a REVERT), it is still included in the block, consumes gas, and its failure is recorded in the receipt.

Re-execution / Rescheduling

Neura does not support dynamic rescheduling or re-execution of transactions after block finalization. Once a transaction is included in a finalized block, its outcome is executed deterministically and committed as-is. No retry or out-of-order execution is performed.

Execution Determinism

Neura ensures deterministic execution across all nodes:

• The EVM is a deterministic state machine — given the same inputs and initial state, all nodes will produce the same final state.

• QBFT ensures that all honest validators agree on the exact list and order of transactions in each block.

Combined, these guarantees ensure that all compliant full nodes arrive at the same post-state and transaction outputs.

Comparison to Ethereum

Please fill in the Neura-specific values in the right-hand column. These will be compared directly to Ethereum’s design. Where applicable, clarify testnet vs mainnet values or ranges.

Transactions/second	~10	~200
Block frequency	12s	2s
Finality	2 epochs (12–18 min)	Instant block finality
Bytecode standard	EVM (Cancun fork)	EVM (Cancun fork)
Max contract size	24 KB	24 KB
RPC API	Ethereum RPC API	Ethereum RPC API
Cryptography	ECDSA	ECDSA
Accounts	Last 20 bytes of keccak-256 of public key under ECDSA	Last 20 bytes of keccak-256 of public key under ECDSA
Consensus mechanism	Gasper (Casper-FFG + LMD-GHOST)	QBFT
Mempool	Yes	Yes
Transaction ordering	Leader’s discretion (in practice, proposer-builder separation / PBS)	Default Besu node transaction ordering
Sybil-resistance mechanism	Proof of Stake (PoS)	Permissioned validator set
Delegation allowed	No (only via liquid staking tokens)	Not currently, but it is planned
Hardware requirements (full node)	4-core CPU, 16 GB RAM, 1 TB SSD, 25 Mbit/s bandwidth