ZENX Whitepaper

1. Abstract

ZENX is an EVM-compatible Layer-1 blockchain engineered for one purpose: making on-chain transactions so cheap and fast that micro-payments, high-frequency DeFi, and casual gaming become economically viable. ZENX runs on Geth with Clique Proof-of-Authority (PoA) consensus, producing a block every 2 seconds with a ~1 gwei gas price — a simple native transfer costs roughly 0.000021 ZENX in fees.

The network ships with a complete on-chain product stack deployed and verifiable at genesis: an ERC-20 ZENX Token with a fixed supply of 33,330,000, a permissionless constant-product DEX (0.3% fee), a relayer-based cross-chain bridge to BNB Chain, and a one-time airdrop program. Every contract address and parameter in this document is verifiable on-chain.

2. Introduction & Problem

Ethereum and its rollup ecosystem deliver strong security but remain costly at the application layer; generic sidechains are cheap but frequently rely on opaque or highly centralized validator sets. ZENX targets the middle ground: a transparent PoA chain whose single designated sealer is publicly known, paired with an honest cost model and a real, deployed product layer — not a promise.

ZENX is designed for use cases where per-transaction cost is the binding constraint:

• Micro-payments and streaming settlement.
• DeFi with native swapping and liquidity provision.
• Gaming and NFT minting/trading (ERC-20/721/1155).
• Cross-chain value transfer via the ZENX ↔ BNB bridge.

3. Architecture

3.1 Consensus

ZENX uses Clique Proof-of-Authority, Geth's built-in PoA engine. Blocks are sealed by an authorized signer (the "sealer"), producing deterministic 2-second block times with immediate single-block finality. There is no mining and no wasted energy; the sealer is compensated by application usage rather than block subsidies.

3.2 EVM Compatibility

ZENX is fully EVM-compatible, activating all major hard forks through the London upgrade from block 0. Any Ethereum smart contract compiles and deploys to ZENX without modification. ERC-20, ERC-721 and ERC-1155 are supported natively, and standard tooling (MetaMask, Remix, Hardhat, web3.js) works out of the box.

3.3 Gas Model

ZENX uses the London (EIP-1559) fee market with an effective gas price of ~1 gwei. A native transfer (21,000 gas) costs ≈0.000021 ZENX, and a typical ERC-20 transfer (≈65,000 gas) costs ≈0.000065 ZENX — negligible at any reasonable valuation. When network demand is low, the EIP-1559 base fee decays below this nominal level, further reducing the burned portion of each fee.

4. Token Model

ZENX distinguishes two assets at the base layer:

• Native gas token — the chain's base currency used solely to pay transaction fees. 1,000,000 units were allocated at genesis to the sealer account to power network operations. It carries no pre-mine to the public and has no block subsidy.
• ZENX Token (ZENX) — an ERC-20 asset with a fixed supply of 33,330,000 and 18 decimals, used across the airdrop, the DEX, and the bridge.

The supply is fixed at genesis and cannot be inflated by third parties: the mint() and burn() functions are restricted to the token owner, providing a credible, auditable supply schedule.

5. Tokenomics & Distribution

The full 33,330,000 ZENX supply is allocated transparently at launch, and every allocation is verifiable against on-chain balances:

6. Decentralized Exchange (ZENX DEX)

The ZENX DEX is a permissionless constant-product automated market maker (AMM) modeled on the x·y = k invariant. It enables trustless ERC-20 swaps and liquidity provision without order books or intermediaries.

• Swap fee: 0.3% (3 / 1000), retained by liquidity providers.
• Pairs: any ERC-20 token pair can be created permissionlessly.
• Liquidity: providers deposit both tokens and receive proportional LP balances, earning fees on every swap.
• Slippage protection: swaps accept a minimum-output parameter to bound slippage.

7. Cross-Chain Bridge (ZENX ↔ BNB)

The ZENX Bridge moves value between the ZENX chain and BNB Chain using a lock-and-mint model supervised by a relayer:

1. ZENX → BNB: a user locks ZENX into the bridge contract; the relayer mints an equivalent amount of wrapped ZENX (wZENX) on BNB Chain.
2. BNB → ZENX: the relayer verifies the burn of wZENX on BNB Chain and releases the locked ZENX back to the user on the ZENX chain.

8. Airdrop Program

ZENX distributes 100 ZENX to every eligible wallet through a one-time claim. The airdrop is non-custodial and trustless — tokens are transferred directly from the airdrop pool contract to the claimant.

• Per-wallet amount: 100 ZENX.
• Eligibility: one claim per address (double-claims are rejected on-chain).
• Pool size: 1,000,000 ZENX (3% of supply).
• Owner tools: batch distribution and remaining-balance withdrawal.

9. Ownership, Security & Governance

All administrative roles are held by the project's designated owner wallet 0xDb76978175bF9Fd68fe55694EefCe7b83ef71584, separating protocol control from the sealer address.

• Token: the owner can mint/burn and transfer ownership. There is no permissionless minting.
• Bridge: the owner sets the relayer, fee, and lock limits.
• Airdrop: the owner manages batch drops and the drop amount.
• DEX: fully permissionless — no owner, no admin keys.

The DEX is deliberately trustless with no admin functions. Remaining administrative surfaces are minimal and documented, with the intent to decentralize further via a Proof-of-Stake transition and community governance in later phases (see Roadmap).

10. Roadmap

11. Network Parameters & Contracts

11.1 Connecting

11.2 Deployed contracts

12. Risks & Disclaimers

• Centralization: ZENX currently operates with a single PoA sealer. This trades decentralization for speed and low cost; it is a deliberate early-stage design choice, with decentralization on the roadmap.
• Bridge: the lock-and-mint bridge relies on a trusted relayer. Bridge security depends on the integrity of the relayer and the BNB-side mint/burn contract.
• Regulatory: ZENX makes no claim of being a security, a currency, or an investment product. Nothing herein is financial advice.
• Technical: smart contracts are provided as-is. While designed to be simple and auditable, they have not undergone a third-party audit at the time of writing.