Architecture v2.0.4

Protocol Architecture

Aeltrix is specified around deterministic execution, bounded state transitions, and validator enforcement. Finality is atomic under the consensus rules.

Execution Model

Deterministic

Deterministic State Machine

Every block produces an identical state transition across all validators. The state root is a Merkle hash computed over accounts, staking, governance, contracts, and fee market state. No randomness. No wallclock dependencies. Byte-for-byte identical output is enforced by consensus.

STATE_ROOT_COMPOSITION

> state_root = merkle_hash(

> accounts_trie,

> staking_state,

> governance_state,

> contracts_storage,

> fee_market_state

> )

> INVARIANT: identical across all nodes

State modelAccount-based (Ethereum-style)

DeterminismEnforced — no RNG, no wallclock

Fork possibilityNone — single proposer with BFT finality

State treeSparse Merkle Trie

Consensus

HotStuff BFT

HotStuff-Inspired BFT

A single proposer constructs blocks at 1-second intervals. Followers validate and sign votes using Ed25519. Quorum certificates aggregate ≥2/3 validator signatures to finalize blocks. Shadow consensus ensures liveness — if the proposer stalls, the protocol continues via view-change.

Parameter	Value
Block time	1 second
Signing scheme	Ed25519
Quorum threshold	≥ ⅔ validator signatures
Proposer model	Single proposer + shadow consensus
Finality type	Deterministic (no reorgs)
Checkpoints	Finalized periodically
Vote admissibility	QC-validated before counting

EVM Compatibility

Shanghai spec

Full EVM Execution via revm

Aeltrix embeds revm v36 (Shanghai specification) for smart contract execution. Contracts deploy and execute with full EVM opcode support including CREATE2, DELEGATECALL, and event logs (LOG0–LOG4). Gas metering is active for execution limits. Existing Solidity toolchains work unmodified.

EVM_CAPABILITIES

> ENGINE: revm v36 (Shanghai)

> RPC: ~30 Ethereum JSON-RPC methods

> DEPLOY: CREATE, CREATE2

> CALLS: CALL, DELEGATECALL, STATICCALL

> EVENTS: LOG0, LOG1, LOG2, LOG3, LOG4

> GAS: Full metering (Shanghai rules)

> COMPATIBLE TOOLING:

> MetaMask, Hardhat, Foundry, ethers.js

EVM enginerevm v36

Spec levelShanghai

JSON-RPC methods~30 (eth_*, net_*, web3_*)

Contract deploymentCREATE + CREATE2

Wallet compatibilityMetaMask, Hardhat, Foundry

Fee Architecture

EIP-1559

Dynamic Base Fee with Constitutional Router

Fees follow EIP-1559 dynamics with a base fee floor of 1 GWEI. Priority fees are capped at base_fee / 2 to prevent fee spikes. A 7% survivability surcharge funds long-term protocol sustainability. Fee distribution percentages are constitutionally immutable.

FEE_FORMULA

> total_fee = base_fee + priority_fee + surcharge

> base_fee = EIP-1559 dynamic (floor: 1 GWEI)

> priority_fee = capped at base_fee / 2

> surcharge = 7% survivability

> transfer_cost ≈ 0.000000002 AELX

Constitutional Fee Router (Immutable)

VALIDATORS

VALIDATORS // 42%

CONTRIBUTORS

CONTRIBUTORS // 18%

BURN

BURN // 12%

Network Layer

libp2p

Peer-to-Peer Networking

Nodes communicate over libp2p with GossipSub for block propagation and a request-response protocol for catch-up sync. New nodes can bootstrap via static bootnode discovery or compressed DB snapshots for fast sync.

Component	Implementation
Transport	libp2p
Block propagation	GossipSub
Catch-up sync	Request-response protocol
Discovery	Static bootnode list
Fast sync	Compressed DB snapshots

Storage

RocksDB

Persistent State Engine

All chain state is persisted in RocksDB with atomic batch writes ensuring crash consistency. The snapshot system creates consistent checkpoints every 100 blocks. Per-transaction receipts are indexed by block for fast retrieval.

STORAGE_ARCHITECTURE

> BACKEND: RocksDB

> WRITES: Atomic batch commits

> SNAPSHOTS: Every 100 blocks

> RECEIPTS: Per-transaction

> INDEX: Block → receipts mapping

> CONSISTENCY: Crash-safe (atomic)

Staking

Validator lifecycle

Validator Registration & Rewards

Validators register by staking a minimum of 10,000 AELX. They transition through Active → Unbonding → Inactive states. Block rewards are distributed equally from the validator bucket each block. Validators can claim rewards, initiate unstaking, and withdraw after the unbonding period.

Parameter	Value
Minimum stake	10,000 AELX
Status lifecycle	Active → Unbonding → Inactive
Reward source	Validator bucket (per block)
Reward distribution	Equal split among active validators
Operations	Claim / Unstake / Withdraw
Unbonding period	Configurable (genesis parameter)

Token (AELX)

Native asset

Token nameAELX

Total supply1,000,000,000 AELX (fixed)

Decimals18 (Ethereum-compatible)

Wallet keyssecp256k1 (BIP32 / BIP44)

Denomination1 AELX = 10¹⁸ base units

Transfer fee≈ 0.000000002 AELX

DENOMINATION_TABLE

> 1 AELX = 1,000,000,000,000,000,000 wei

> 1 GWEI = 1,000,000,000 wei

> transfer_fee ≈ 2,000 wei ≈ 0.000000002 AELX

> KEY_DERIVATION: secp256k1 // BIP32 / BIP44

> ADDRESS_FORMAT: 0x... (Ethereum-compatible)