Eternix: Unified Protocol Whitepaper & Design Specification Abstract Eternix is a Layer-1 blockchain designed around long-term economic coherence, deterministic behavior, and strong resistance to structural failures observed in classical Proof-of-Stake systems. It introduces Proof of Ash (PoAsh) , a consensus mechanism combining irreversible burn-based weight with ongoing, fully slashable collateral. Eternix is EVM-compatible, economically explicit, and architected for predictable operation over decades rather than speculative cycles. This document consolidates the complete Eternix design: consensus, validator lifecycle, monetary policy, fee handling, execution environment, first-class tokens, governance scope, and genesis bootstrap. It is intended to serve as the canonical technical reference for the protocol. 1. Design Philosophy Eternix is built on a few uncompromising principles: • Irreversibility matters. Consensus weight and fees must not be replayable. • Validators must retain exposure. Security cannot depend on liquid funds alone. • Economics must be legible. Monetary policy should be smooth, explicit, and auditable. • Throughput should be practical, not theatrical. • Compatibility without inheritance. EVM compatibility without Ethereum’s economic assumptions. The protocol is intentionally minimal at the execution layer and rigorous at the economic layer. 2. Core Architecture 2.1 Layer Model • Execution: EVM-compatible virtual machine (XVM) • Consensus: Proof of Ash (PoAsh) • Scheduling: Epoch / Sub-Epoch system • Accounting: First-Class Tokens (protocol-level) Eternix rewrites the validator and monetary machinery while preserving developer familiarity. 3. Proof of Ash (PoAsh) Consensus PoAsh combines two commitments: Permanent burn to create non-transferable consensus weight (tickets) Proportional vault collateral that remains slashable over time 1. 2. 1 This prevents long-range attacks, stake replay, and cost-free exits. 3.1 Tickets • Created by burning ETX • Non-transferable • Permanent unless explicitly retired • Each ticket has a unique ID • Determines leader selection probability 3.2 Validator Vault Each validator maintains a vault holding: • Initial bond • Per-ticket collateral • Earned block rewards Vault invariants: required_minimum = initial_bond + ticket_count × BOND_PER_TICKET Vault funds are: • Non-transferable • Fully slashable • Withdrawable only under strict conditions 3.3 Validator States • ACTIVE • PAUSED_LOW_VAULT • PUNISHED_COOLDOWN (muted) • INACTIVE_VALIDATOR • JAILED 4. Validator Lifecycle 4.1 Registration • Deposit ≥ MIN_BOND into vault • Register validator • Begin with zero tickets 4.2 Ticket Creation burn(TICKET_COST) create_ticket() Ticket cost is governance-adjustable. 4.3 Ticket Retirement To prevent exit abuse: • MAX_RETIRE_PER_EPOCH limit • Excess retirements incur cooldown • Validators remain slashable during exit 2 4.4 Slashing & Mutes • Slashing burns a percentage of vault • Mutes disable validation for a cooldown • Vault refill does not cancel punishment • Severe offenses jail tickets permanently 5. Leader Selection PoAsh uses deterministic ticket lottery with bucketed selection to preserve proportional fairness while reducing per-slot computation. 5.1 Ticket Buckets Tickets are organized into 256 buckets , separated into functional categories. Bucket Categories DEAD (1 bucket) • Contains tickets that are permanently inactive • All retired and jailed tickets are moved here • Never selectable • Tickets in DEAD have zero probability of leadership MUTED (1 bucket) • Contains tickets that are temporarily inactive • Tickets from validators in PUNISHED_COOLDOWN or PAUSED_LOW_VAULT states reside here • Never selectable while in this bucket • Tickets automatically move back to ACTIVE when validator state is restored ACTIVE (254 buckets) • Contain tickets from validators in ACTIVE state • These buckets are selectable during leader selection • Tickets inside ACTIVE buckets fully participate in consensus Buckets are disjoint, protocol-managed, and carry no economic meaning beyond eligibility and performance optimization. 5.2 Bucket Selection For each slot: • A bucket is selected with probability proportional to the number of tickets it contains • Only tickets inside the selected bucket participate in leader scoring This preserves the invariant: X% of total tickets ⇒ X% chance of leadership while reducing selection cost from O(N) over all tickets to O(k) over a single bucket. 3 5.3 Ticket Scoring R_s = hash(prev_slot_hash || slot) score = hash(R_s || ticket_id) lowest score wins • Seeded per slot • Grinding-resistant • Censorship-resistant 6. Epoch & Time Structure • Slot time: 3 seconds (fixed) • Sub-epoch: 1 hour • Epoch: 24 sub-epochs (24 hours) 6.1 Fixed-Time Slots Each slot is exactly 3 seconds long. Block construction is time-budgeted. • The slot leader must begin publishing the block no later than 2100 ms into the slot • Only transactions fully executed before the 2100 ms deadline are included • If execution is ongoing at 2100 ms, the block is finalized immediately • \~900 ms of the slot are reserved for network propagation If a validator proposes a block before the slot ends, it is buffered and only broadcast at the 3-second boundary. This guarantees: • Uniform 3-second block time • Stable propagation window • Protection against execution overruns Early proposals do not accelerate the chain. 6.2 Sub-Epoch Operations • Reward accrual • Proposer rotation 6.3 Epoch Operations • Ticket retirement progression • Slashing finalization • Validator churn This provides predictable cadence without timing variance or high-frequency instability. 7. Monetary Policy 7.1 Native Token: ETX • Fixed decimals: 10 • Smallest unit: 1 quark = 10⁻¹⁰ ETX • Unit of account for all security economics 4 7.2 Base Issuance • Initial inflation: 6% • Annual decay: 10% • Inflation floor: 0.5% • Applies to current supply Smooth, asymptotic issuance—no halvings. 7.3 Burn-Offset Issuance To counter permanent consensus burns: I = I ₀ + k × B • B = smoothed consensus burns (tickets + slashing + fees) • k ∈ [0.25, 0.75] • Genesis default: k = 0.5 Burns are never reversed; offset is forward-looking. 8. Fees • All transaction fees are burned. • No fees are routed to treasuries, pools, or governance-controlled accounts. • Fee burns are permanent and irreversible. Rationale: • Preserves semantic purity: fees represent consumed chain resources • Prevents discretionary fund accumulation • Aligns economic activity directly with supply contraction • Strengthens long-term scarcity without rent extraction Fee burns are included in burn-offset issuance smoothing but are never refunded or redirected. 9. First-Class Tokens (FCTs) FCTs are protocol-level fungible assets. 9.1 Properties • Native accounting • No embedded logic • Deterministic transfer semantics • Optional governance constraints ETX is the canonical First-Class Token. 9.2 Fees with FCTs • Approved FCTs may be used to pay fees • The fee-paying token is burned All fee payments ultimately result in permanent value destruction under protocol control. 5 9.3 Special Handling: wETX • wETX is treated as ETX for fee logic • Paying fees in wETX burns the wETX • The backing ETX is also burned This behavior is invariant and requires no settlement mechanism. 10. Execution Environment (XVM) • Full EVM compatibility • Solidity, Hardhat, Foundry supported • No exotic execution model • Deterministic gas accounting Throughput Targets • Block gas target: 16M • Intrinsic tx gas: 1,000 • \~100 TPS for simple transfers • Base fee: 10 quarks / gas 11. Governance Scope Governance may: • Adjust ticket cost & bonds • Adjust inflation parameters (within bounds) • Approve FCT fee eligibility • Adjust burn-offset coefficient k Governance may not : • Redirect or reclaim burned fees • Seize vaults • Override slashing • Mint arbitrarily 12. Protocol-Generated Blocks Eternix does not rely on a special genesis bootstrap validator. 12.1 Protocol Block Conditions The protocol generates a block when: • No eligible tickets exist • The selected slot leader fails to begin publishing a block before the 2100 ms publish deadline 12.2 Block Semantics • Validator inactivity: protocol block is empty • No eligible tickets: protocol block may include only: • Ticket burn transactions • Wallet → vault transfers All other transactions are forbidden. 6 12.3 Rewards • Protocol-generated blocks produce no rewards • Validator-proposed blocks are the sole source of issuance Protocol blocks exist purely to preserve liveness and deterministic time progression. 13. Security Properties • Long-range attack immunity • Exit-griefing resistance • Deterministic history • No weak subjectivity • Permanent economic weight • No protocol-controlled fee hoards 14. Conclusion Eternix is designed to be boring in the ways that matter: predictable economics, legible rules, and durable security. By burning fees, burning tickets, and burning slashed collateral, Eternix ensures that all consumed security and execution resources leave a permanent economic trace. The result is a protocol whose incentives are simple, auditable, and resistant to capture—intended to remain sound long after transient narratives fade. 7