LIQUA · L1 CHAIN SPEC

1 · Vision & positioning

Liqua is a spot exchange today (off-chain orderbook + 0x-style on-chain settlement + UniV2 AMM + flash-cross Matchmaker). The exchange is the application. The chain underneath should be a boring, reliable execution surface for that application — not the product.

The reason to ship a native chain instead of just deploying on Base / Arbitrum / Ethereum:

• Native gas token (LIQUA) means the project captures gas revenue + protocol fees, not just protocol fees.
• Block-level priority for Liqua transactions — the sequencer / block producer can deterministically order Liqua fills before other contract calls, removing MEV exposure on our own protocol.
• "Easy to mine" lowers the barrier to running a node; that's the user's stated goal and we honor it.

2 · Stack at a glance

3 · Consensus choice

Three candidates, ranked:

PoW (recommended)

Pros: zero-trust to bootstrap (no genesis validator pre-sale), familiar mental model for users, "easy to mine" requirement maps directly. Pool infrastructure already exists for the candidate algos. Permissionless miner entry.

Cons: high energy cost at scale, slower finality than PoS, vulnerable to 51% attack until hashrate matures (mitigated by checkpoint contract on Ethereum for the first ~year).

PoS (rejected)

Lower energy and faster finality, but requires a genesis validator set that's hard to bootstrap fairly. Doesn't satisfy "easy to mine with a pool" — staking is not mining. Would also concentrate power early in whoever gets the airdrop.

Hybrid PoW + Checkpoints (interesting)

PoW for liveness, but with a periodic checkpoint posted to Ethereum L1 (every ~256 Liqua blocks) that finalizes earlier blocks. Removes the 51%-attack window after checkpoint depth. Same dev cost as plain PoW + one small Solidity checkpoint contract. Recommended for phase 1.

4 · Reward mechanism — decayed PoW + partial validation + keypair claim

Three coupled ideas, all wired in per-block rather than per-epoch:

(a) Reward decays inside each block interval — fast twitch wins

Let t be seconds since the prior block was sealed. The available reward decays exponentially:

R(t) = R_max · e^(−λt)        where  λ = ln(2) / 30s  ⇒  half-life 30s

Why decay? The fastest finder captures the bulk of the reward (the "fast-twitch wins" property the user asked for). Slow miners aren't excluded, but the economic signal collapses if no one finds a block for minutes — which also smooths the long-tail of partition-induced gaps. Aggregate emission is bounded by the integral of R(t) over realized intervals; integrate at the 10s target and you get a predictable supply curve.

(b) Partial validation — more verification work = bigger validator share

Once a primary miner submits a valid solution, the per-block reward R(t) is split:

• 70% → primary miner (whoever found the nonce first)
• 30% → validator pool, split among nodes that submit valid validation proofs

A validation proof carries a depth d ∈ {1, 2, 4, 8, 16} — higher depth = more re-computation of the primary's PoW chain = bigger share. Validator i with depth d_i earns:

validator_i_share = 0.30 · R(t) · d_i / Σ d_j

This achieves two things simultaneously: more eyeballs on every block (extra independent verification → security) and a non-zero income path for slow miners (race-losers can still earn by validating). Fast-twitch still controls because 70% goes to the primary; validators split the remaining 30%.

(c) Block reward → ephemeral keypair → claimed on L2 after K confirmations

For each new block N, the protocol deterministically derives an ephemeral keypair via VRF:

seed_N  = H(parentHash || difficulty_N || minerPubKey)
priv_N  = VRF(minerPrivKey, seed_N)        // only this miner can compute
addr_N  = address(pubKeyOf(priv_N))

The decayed + split reward is paid to addr_N — not directly to the miner's wallet. To claim, the miner:

1. Waits K confirmations on the Liqua chain (target K = 12 → ~2 min at 10s blocks).
2. Calls the L2 Reward Claim contract with: (priv_N, sig_over_destination_wallet, merkleProof_of_block_N_canonicality).
3. L2 verifies the proof against the L1's confirmed head, checks priv_N matches addr_N, then transfers the reward to the chosen destination wallet.

5 · Hashing algorithm — RandomX as cellular metabolism

"Easy to mine with a pool" is a value judgment, not a single algo. Three real candidates:

Recommendation: RandomX

• "Easy" in the spirit the user meant: anyone with a CPU can mine. No GPU required.
• Pool software (xmrig + nodejs-pool, MoneroOcean fork) ports cleanly.
• Battle-tested in Monero for 5+ years — known security profile.
• Implementation: link librandomx from the node's PoW verifier; expose a "getwork" RPC that pools speak.

Choose KawPow instead if the target user has a GPU rig. KawPow → hashrate / W is much better than RandomX on GPU. Both are equally "pool-mineable".

What it represents · molecular framing

RandomX isn't picked just because it's mineable — it maps cleanly onto the molecular OS vocabulary the rest of Liqua is written in:

A fully bespoke "MolHash" could compose RandomX (cytoplasm) → Blake3 (membrane) → KILLER_T verification phase, but inventing novel cryptographic primitives is the kind of thing that costs years of security review and routinely ships exploitable in v1. Pick RandomX. Brand it as cellular metabolism in the docs and marketing. The narrative is honest, the security is borrowed from a battle-tested algorithm, and the molecular framing differentiates Liqua without inviting "rolled their own crypto" criticism.

5 · Supply & gas (native LIQUA)

Same 100M hard cap as today's ERC-20, so the bridge can be 1:1. Emission curve:

// reward per block
epoch 0 (blocks 0 – 6,307,200)        5   LIQUA   // ~2 yr at 10s blocks
epoch 1 (blocks 6,307,201 – 12,614,400) 2.5 LIQUA
epoch 2 (12,614,401 – 18,921,600)      1.25 LIQUA
epoch 3 (18,921,601 – 25,228,800)      0.625 LIQUA
...halve every ~2 years until 100M cap

Gas is paid in LIQUA. Protocol fees from the Exchange (current setting: 0–100 bps) go to LiquaStaking as today — but on the native chain a portion (e.g. 20% of gas burned + 100% of protocol fees) can be routed to stakers, the rest burned. setFee stays governance-controlled.

7 · Locked staking (veLIQUA) & locked-liquidity registry

Today's LiquaStaking contract has no lock — you stake, unstake, claim whenever. The native chain adds a locked tier: commit LIQUA for a fixed period in exchange for a higher reward multiplier and proportional governance weight. The unlocked tier still exists; locking is a choice.

Sliding scale: 1 day → 4 years

Formula: boost = 1 + min(lockDuration, 4y) / 4y. Linear all the way to the 4y cap.

Hard lock — no early withdrawal, no decay-down

Withdrawal is impossible before the unlock date. No emergency exits, no slow decay-down (i.e. not Curve's veCRV model where weight bleeds linearly). The lock IS the commitment; soft-locks dilute the signal that lock duration is supposed to broadcast.

Trade-off: locked users lose liquidity for the duration. Mitigation: a secondary market for tokenized lock receipts (ERC-721 wrapping each position) can exist off-protocol — the chain doesn't bless it, but doesn't forbid it either.

Voting weight = boost × stake

Locked stake earns proportionally more rewards AND more governance weight (see §9). A holder with 1,000 LIQUA locked 4 years has 2,000 vote weight; the same 1,000 unlocked has 1,000. This aligns governance power with skin-in-the-game — short-term participants can't outvote long-term committers.

Locked-liquidity registry — on-chain transparency as marketing

Every lock is on-chain by construction. A public registry page (/locked.html) reads the staking contract and surfaces this as a marketing transparency layer — call it "proof of commitment":

• Top 100 lockers — address (with blockie), amount, unlock date, multiplier, $ value
• Live totals — total LIQUA locked, total $ value locked, % of circulating supply locked
• Average lock duration — weighted by stake (a healthy chain shows the weight cluster around 2y+)
• Time series — new locks/day, unlocks/day, net flow over rolling windows
• Cliff calendar — upcoming unlocks within next 30/90/365 days (so the market knows what supply is coming)
• Duration distribution scatter — stake size on Y, lock duration on X, dot = a position. Visualizes whether the chain is dominated by short or long committers.

This page is marketing precisely because the underlying data is verifiable on-chain. No "we have $X locked" press release — just a live chart anyone can audit by querying the contract directly. The chart is the marketing.

8 · Block structure & time

10-second target. Block format:

{
  version:    1,
  parentHash: "0x…",
  number:     42,
  timestamp:  1780000000,
  miner:      "0x…coinbase",
  difficulty: 12345678,           // retarget every 2016 blocks (~5.6 hr)
  nonce:      982374,             // PoW nonce
  stateRoot:  "0x…",              // EVM state Merkle root
  txRoot:     "0x…",
  receiptRoot:"0x…",
  extraData:  "liqua/1.0.0",
  randomxSeed:"0x…",              // rotates every 2048 blocks (RandomX requirement)
}

9 · Governance — 98% supermajority for changes & rollbacks

Two protocol-level operations are gated by an intentionally near-unanimous bar:

(a) Protocol changes

Any change to chain rules — block reward formula, fee bps, hashing algorithm choice, bridge validator set, governance parameters themselves — requires:

• 98% supermajority of veLIQUA-weighted YES votes (NO + abstain together ≤ 2%)
• 50% quorum — at least half of all outstanding veLIQUA weight must participate (YES + NO + explicit ABSTAIN). Stake that doesn't vote at all doesn't count toward quorum.
• 7-day vote window — opens at proposal time, closes 7 days later
• 48-hour timelock after passing — last-chance exit window for users who disagree before the change takes effect

(b) State rollbacks

If the chain produces a block the community considers invalid (deeply embedded bug exploitation, bridge compromise, etc.), a rollback proposal can revert state to an earlier block. Same gating as protocol changes, plus:

• Rollback target must be within the last 24 hours (8,640 blocks at 10s). Older rollbacks are categorically forbidden — past that depth, too much economic activity has settled and rewinding it would harm bystanders more than the original incident did.
• Rollback proposals trigger a chain freeze at proposal time — block production halts pending the vote. This is heavy but unavoidable: you can't safely roll back a chain that's still producing blocks on top of the to-be-rolled-back state.

Why 98% — trade-offs (honest)

The bias is intentionally toward inaction. The bet is that users who want stable, hard-to-change rules will pay an illiquidity premium (longer locks, more capital committed) precisely because the rules can't be rugged on them by a 51% governance attack. If Liqua wanted to be governed like a startup, it would use 50%. It doesn't.

Vote execution mechanics

• Proposal threshold: anyone holding ≥1,000 veLIQUA can submit a proposal. Costs a small deposit (refunded if quorum is met, slashed if not — anti-spam).
• Vote weight snapshot: taken at proposal submission time. Buying veLIQUA after a proposal is open doesn't increase your vote weight on it. Prevents flash-loan / last-second whale attacks.
• Vote types: YES / NO / ABSTAIN. ABSTAIN counts toward quorum but not toward the supermajority denominator.
• Delegation: holders can delegate vote weight to another address (one-level deep, no transitive delegation chains).
• Execution: after timelock expires, anyone can call execute(proposalId) on the LiquaGovernance contract. The contract makes the encoded calls.

10 · Execution layer (EVM-compatible)

Use the existing EVM. Reasons:

• Our Solidity (Exchange, AMM, Matchmaker, Staking, LiquaToken) ports unchanged.
• MetaMask + ethers.js + the entire dev ecosystem works on day 1.
• Tooling (Hardhat, Foundry, Tenderly) requires zero adaptation.

Implementation path: fork Reth (Rust Ethereum execution client), strip the PoS consensus engine, replace it with our RandomX PoW + checkpoint engine. Reth has the cleanest module boundary for this swap.

8 · Mining pool architecture

A pool is three things: a stratum server that gives miners work, a share validator, and a payout system.

┌──────────────┐  getJob   ┌──────────────────┐  submitBlock   ┌────────────┐
│ miner (CPU)  │ ─────────►│ stratum server   │ ──────────────►│ liqua node │
│              │ ◄─────────│                  │ ◄──────────────│            │
└──────────────┘  newWork  └────────┬─────────┘     newJob     └────────────┘
                                    │
                                    ▼
                          ┌──────────────────┐
                          │ share validator  │ → DB → payout cron
                          └──────────────────┘

For RandomX, pool software exists and is mature (nodejs-pool fork, MoneroOcean's setup). For KawPow, MiningPoolHub has a reference. Forking either + pointing at our node's stratum RPC is ~2 weeks of work.

Payout choice: PPLNS (Pay Per Last N Shares) — discourages pool-hopping, fair across luck. PPS is friendlier to small miners but riskier for the pool operator until hashrate is established.

9 · Bridge (Ethereum ↔ Liqua)

Phase 1: lock-mint with N-of-M multisig

• Ethereum side: LiquaBridge.lock(amount) burns/locks Ethereum-side ERC-20 LIQUA, emits Locked(user, amount, nonce).
• Validators (initially 5-of-9) observe the event, sign a mint message, post it to Liqua chain.
• Liqua side: LiquaBridge.mint(user, amount, nonce, signatures) requires ≥5 valid sigs.
• Reverse direction: burn on Liqua → 5-of-9 sigs → unlock on Ethereum.

Phase 2: ZK proof bridge

Replace the multisig with a zk-SNARK that proves "this Ethereum block contained Locked(user, amount, nonce)". The Liqua mint function verifies the proof against a known Ethereum block hash (provided by a trustless light-client or oracle like Hashi). No trusted validators. Significantly more expensive engineering — probably year 2.

10 · Rollout plan (what we'd actually build)

Rough total: ~11 person-quarters with a 4–5 person team of (Rust + Solidity + DevOps) seniors. Realistic budget: $1.5–2.5M including external audits.

11 · What this document is NOT

• Not shipped: a Liqua L1 client. No native chain runs today.
• Not shipped: a real mining pool. The /mining-demo.html page is an educational in-browser hasher, not pool infrastructure.
• Not shipped: the Ethereum ↔ Liqua bridge. Liqua tokens today are an ERC-20 on whichever EVM chain you deploy to.
• Shipped: everything in orderbook-dex/contracts/ (Exchange, AMM, Matchmaker, LiquaToken, LiquaStaking) + the relayer + the trading/profile/staking/explorer/docs/mining-demo pages.

If you want any of the unshipped pieces actually built, the rollout plan above is the honest answer to "how long" and "how much."