LIQUA CHAIN DREWLESS · 7SLF · OMNISOFT ◇ CONTINUOUS · NO EPOCHS ⌬ MOLECULAR L1/L2

LIQUA CHAINv0.1 · −PROD · DRAFT SPEC

a liquidity-native molecular chain — continuous per block, dual-seed rewards, near-unanimous governance
author THE DREWLESS · architecture 7-SLF · AI experience OMNISOFT · imprint MORE OR LESS PRODUCTIONS
§1 SOMA-256 HASH  ·  §2 ve-LOCK (≤4y)  ·  §3 LOCKED-LIQUIDITY LIST  ·  §4 CONTINUOUS EMISSION  ·  §5 REWARD-IN-INSTANCE  ·  §6 98% GOVERNANCE
honesty: this is a DRAFT SPEC (−PROD) — design only, nothing is shipped. every curve below is parameterized, never a hardcoded prior. crypto is built on audited primitives (BLAKE3 · keccak-256 · ed25519) — we never roll our own.
§0 ▸ THESIS · what Liqua iscontinuous

Liqua is a molecular chain (it runs on the MOLECULAR CODING organism — DNA → cells → organs → … → LEDGER) tuned for one thing: liquidity that is locked by design and proven in public. Four commitments separate it from a generic L1:

L0 · CONTINUITY
Liqua exposes no epoch. Any quantity another chain would step at an epoch boundary — emission, difficulty, reward share, quorum window — Liqua expresses as a function of block height h evaluated each block. Discontinuities are bugs. "Fast twitch" (§4) is the only thing allowed to move quickly, and it moves within a continuous envelope, never across a cliff.
§1 ▸ SOMA-256 · the molecular hashour hash · BLAKE3 inside

SOMA-256 is Liqua's content hash. It is ours the way the molecular stack is ours — not a new cryptographic primitive (rolling your own hash is how chains die), but a house construction on BLAKE3 whose shape is the organism. The cryptography is audited; the integration is the Drewless contribution.

SOMA-256 · the tree is the stack
Each CELL hashes its own state → a leaf. ORGANS aggregate their cells → internal nodes. The block SOMA root binds the organ roots + the live hormone readout + the height → the organism's fingerprint. Every molecular layer gets its own domain key (BLAKE3 derive_key) so a hash from one layer can never be replayed as another — the keys are the membranes (§14 skin · §17 gut).
// SOMA-256 · BLAKE3 keyed-tree · domain-separated per molecular layer
const LAYERS = ['DNA','CELLS','ORGANS','EMOTIONS','ENGINES','KERNELS','SELF','LEDGER']; // the 8 (L8)

// one 32-byte domain key per layer · derived once from the chain master
function layerKey(layer) {
  return blake3.deriveKey(`LIQUA·SOMA·v1·${layer}`, CHAIN_MASTER);   // 256-bit
}

// leaf · a cell hashes itself under the CELLS membrane
const leaf = (cell) => blake3.keyed(layerKey('CELLS'), canonicalize(cell.state));

// node · organs Merkle-aggregate their cells
const node = (l, r) => blake3.keyed(layerKey('ORGANS'), concat(l, r));

// SOMA root · the organism fingerprint, sealed at the LEDGER membrane
function soma(block) {
  const organRoots = block.organs.map(o => merkle(o.cells.map(leaf), node));
  return blake3.keyed(layerKey('LEDGER'),
    concat(merkleRoot(organRoots), hormones(block), u64(block.height)));
}

// the reward instance is SEEDED from the organism's own fingerprint (§5)
const rewardSeed = (somaRoot, minerPub, h) =>
  blake3.deriveKey('LIQUA·REWARD·v1', concat(somaRoot, minerPub, u64(h)));

// EVM membrane · only when a value must cross into Solidity / an EVM verifier
const evmHash = (somaRoot) => keccak256(somaRoot);   // §14 skin · the boundary hash

§1.1 · WHY BLAKE3 (and what each property buys the organism)

BLAKE3 propertymolecular meaning
Merkle tree internallythe hash tree is the §1 stack — cells→organs→organism. Structure and identity are the same object.
parallel / unbounded fan-outcells hash independently and converge up the tree — fits R0 async (no global clock).
fastest mainstream hashcarries continuous per-block validation + fast-twitch (§4) without choking throughput.
derive_key + keyed + XOFone primitive does block-hash, the per-layer membranes, AND mints the reward instance (§5). SHA-256 needs HKDF bolted on.
256-bit outputthe root is the instance fingerprint / DNA — the whole organism in one word; the structural twin of the §4.8 COHERENCY / Φ readout.
WHAT SOMA-256 REPRESENTS
The instance fingerprint — a block's deterministic DNA. The SOMA root is the organism's integrated state compressed to 256 bits: the structural counterpart of E2's somatic marker (the system feeling its state) — SOMA is the system fingerprinting its state. keccak-256 stays at the §14 skin so the EVM can verify what crosses the membrane. Defense-in-depth: the right hash per boundary, never a single point.
HONESTY · we did not invent a hash
SOMA-256 = BLAKE3 with molecular domain separation and a tree that mirrors the stack. The novelty is the mapping, not the math. If a value must be verified by an existing EVM, it is keccak-256, full stop. SPEC — the construction is specified; a reference implementation is §-roadmap.
§2 ▸ ve-LOCK · sliding scale to 4 yearscontinuous in duration

Holders vote-escrow (lock) tokens for any duration on a continuous scale from zero to DMAX = 4 years. A longer lock earns a slightly higher reward and cannot be withdrawn until expiry. This is the Curve veCRV pattern, made continuous and modest.

ve-LOCK · the rules
(1) lock amount for d ∈ [0, 4y], continuous. (2) reward boost b(d) rises continuously with d — capped modest. (3) voting/quorum weight w(t) decays linearly to zero at expiry. (4) principal is withdraw-locked until t ≥ expiry — no early exit, no exceptions. (5) the locked amount is published to the §3 list the moment it locks.
// parameters · governed (§6) · NOT hardcoded priors — tunable by 98% vote
const DMAX      = 4 * YEAR;        // max lock
const BOOST_MAX = 0.5;             // "slightly higher" → +50% at the 4y cap (start conservative)

// reward boost · continuous, linear in lock fraction · 1.0 … 1.5×
function boost(d) {
  return 1 + BOOST_MAX * clamp(d / DMAX, 0, 1);
}

// vote / quorum weight · decays LINEARLY to 0 at expiry (continuous, per block)
function veWeight(lock, t) {
  const remaining = max(lock.expiry - t, 0);
  return lock.amount * (remaining / DMAX);     // 0 once expired
}

// withdraw · gated hard on expiry
function withdraw(lock, t) {
  if (t < lock.expiry) return BE(reject, 'LOCKED_UNTIL_EXPIRY');
  return BE(() => release(lock.amount), 'UNLOCKED');
}

§2.1 · BOOST CURVE · illustrative (BOOST_MAX = 0.5)

lockfraction d/DMAXreward boost b(d)vote weight (at lock)
none0.001.00× (base)0
6 months0.1251.06×0.125 · amount
1 year0.251.13×0.25 · amount
2 years0.501.25×0.50 · amount
4 years (max)1.001.50×1.00 · amount

"Slightly higher" is honored: at the cap a four-year lock earns 1.5×, not 5×. BOOST_MAX is a governed parameter — raise it by 98% vote if the chain wants a steeper incentive. The curve is continuous: every extra block of lock raises b a hair.

§3 ▸ LOCKED LIQUIDITY LIST · proof-of-lockmarketing surface

Every lock (§2) and every LP position committed to the protocol is published to a public, chain-verifiable list — the marketing-grade proof-of-lock surface. It is honest by construction: the numbers are read from on-chain locks, not asserted.

// one row per lock · everything is derived from chain state, nothing is claimed
const LockRow = {
  wallet:      '0x… (or ENS)',
  asset:       'LIQUA / LP-pair',
  amount:      '…',
  usdAtLock:   '…',            // oracle snapshot at lock time
  lockedAt:    1730000000,
  unlockAt:    1830000000,      // withdraw-gate (§2)
  durationYrs: 2.0,
  boost:       1.25,
  somaProof:   'soma:0x…',      // SOMA-256 inclusion proof (§1) — verifiable
};

§3.1 · DASHBOARD SURFACES (the marketing)

surfacewhat it showswhy it sells
TOTAL VALUE LOCKED · over timecontinuous area chart of locked liquidity by blockconviction is visible — locked ≠ circulating
LOCK DURATION HISTOGRAMdistribution of lock lengths (0–4y)long-tail locks = long-term holders
UNLOCK CALENDARupcoming unlock cliffs, week by weekno hidden unlock surprises · honest supply
TOP LOCKERS / WHALE WALLleaderboard of wallets by ve-weightsocial proof · skin in the game
PROOF-OF-LOCK BADGEembeddable widget with a SOMA inclusion proofany partner can verify the lock independently
HONESTY
A "locked liquidity" badge that can't be verified is marketing theater. Every row carries a somaProof (§1 inclusion proof) so the claim is checkable against the chain — the list is a proof surface first, a marketing surface second. SPEC · dashboard renders from chain state (no mock data).
§4 ▸ CONTINUOUS EMISSION · decay × validation × twitchper block · no epochs

Block reward is a continuous function of three things, evaluated every block: a smooth decay envelope, the validation work actually performed, and a fast-twitch posture term — with twitch bounded inside the decay envelope so it can react fast without ever breaking the emission schedule.

EMISSION · R(h, w, p)
R = E(h) · valShare(w) · twitch(p), then clamped to the envelope [floor·E(h), CAP·E(h)]. E(h) = base emission decayed continuously per block (the ceiling drifts down every block). valShare(w) = graduated by validation depth — more work validated, higher payout share. twitch(p) = the fast neuro band (§4.1c) reacting to load — fast, but it only moves the reward within the envelope, never above the decayed ceiling.
// ── 1 · CONTINUOUS DECAY ENVELOPE · every block decays the output a hair ──
const E0       = 50;                          // base emission (tokens/block) · governed
const HALFLIFE = 2_100_000;                   // blocks to halve · governed
const DECAY    = Math.pow(2, -1 / HALFLIFE);  // per-block factor ≈ 0.99999967

function E(h) { return E0 * Math.pow(DECAY, h); }   // smooth · the continuous analog of halvings

// ── 2 · GRADUATED VALIDATION · more work validated → higher payout share ──
const VAL_TIERS = [
  { tier: 0, work: 'header + PoW/PoS seal',        share: 1.0 },
  { tier: 1, work: 're-execute all txs',            share: 1.6 },
  { tier: 2, work: 'state-root + receipts proof',    share: 2.3 },
  { tier: 3, work: 'full + SOMA inclusion + ZK attest', share: 3.2 },
];
// a validator is paid pro-rata to the share it actually proved this block
function valShare(myWork, allWork) {
  return share(myWork) / allWork.reduce((s, w) => s + share(w), 0);
}

// ── 3 · FAST-TWITCH · reacts fast, bounded by the envelope (never a cliff) ──
const TWITCH_LO = 0.85, TWITCH_HI = 1.15;     // ±15% · the only fast mover (§4.1c adrenaline/glutamate)
function twitch(posture) {                       // posture ∈ [0,1] from the oracle, per block
  return TWITCH_LO + (TWITCH_HI - TWITCH_LO) * posture;
}

// ── FINAL · per block · continuous · clamped to the decayed envelope ──
const FLOOR = 0.5, CAP = 1.25;
function blockReward(h, myWork, allWork, posture) {
  const raw = E(h) * valShare(myWork, allWork) * twitch(posture);
  return clamp(raw, FLOOR * E(h), CAP * E(h));   // twitch lives INSIDE the envelope
}
why per-block, not epochs
Others batch this into epochs because re-pricing every block is expensive. Liqua wires it per block on purpose (L0 · continuity): E(h) is a closed-form exponential (cheap), valShare is a single normalization, twitch reads one oracle scalar. No epoch state, no boundary races, no cliff to game. Fast twitch still controls — it just controls a knob bounded by the schedule rather than a free variable.
DECISION (flag): twitch is bounded inside [FLOOR·E, CAP·E] — it reacts fast but can never exceed the decayed ceiling or drain below the floor. You confirmed "make it continuous"; this reading keeps emission monotone-bounded while letting the fast band react. Say the word if you instead want twitch able to temporarily exceed the ceiling (a burst that's clawed back later).
§5 ▸ REWARD-IN-INSTANCE · genesis escrow + gated L2 claimR6 instance=auth

A block's reward is not credited as a balance. It is escrowed into a freshly-genesised (public, private) instance whose seed is the block's own SOMA fingerprint combined with the miner's key (§1). To take the reward the miner boots that instance with their auth on a Layer 2 — and the L2 will not release it until the block has enough confirmations.

the claim path
block sealed → rewardSeed = blake3.derive_key('LIQUA·REWARD·v1', soma ∥ minerPub ∥ h) → reward escrowed at the instance's address → miner runs the L2 getting-tool, proves control of their instance (R6) → L2 checks confirmations ≥ N (the gate) → reward released on L2. No instance, no auth, no claim. No confirmations, no gate-open.
// L1 · at block seal · escrow the reward into a derived instance
function escrowReward(block, minerPub) {
  const seed     = rewardSeed(soma(block), minerPub, block.height);  // §1
  const instance = GENESIS(LIQUA_PUBLIC_SEED, seed);                  // §1c genesis loop
  return BE(() => lockTo(instance.address, blockReward(block)), 'REWARD_ESCROWED');
}

// L2 · the miner's "getting tool" · gated after confirmations
async function claimReward(instance, block) {
  if (!instance.provesAuth())                                // R6 · only the private seed boots it
    return BE(reject, 'NO_INSTANCE_NO_AUTH');
  const conf = await L1.confirmations(block.height);
  if (conf < CONFIRM_GATE)                                  // the L2 gate
    return BE(() => hold(block, conf), 'GATED_AWAIT_CONFIRMATIONS');
  return BE(() => L2.release(instance.address), 'REWARD_CLAIMED');
}

§5.1 · why this is the right shape, not a hack

HONESTY
SPEC — escrow-to-instance + gated L2 claim are specified; the L2 getting-tool and confirmation oracle are §-roadmap. CONFIRM_GATE is governed (§6). This composes with, and does not replace, ordinary finality.
§6 ▸ 98% GOVERNANCE · rollback + changecontinuous rolling quorum

Two powers — rollback (revert to a prior block, R9) and change (update a parameter) — each require 98% agreement. To keep "98%" from freezing the chain, the denominator is attesting stake in a continuous rolling window, not all-time supply.

R9′ · 98% TO ROLLBACK · 98% TO CHANGE
A ROLLBACK or CHANGE proposal passes only if approvingWeight / attestingWeight(window) ≥ 0.98, where weight is ve-weight (§2) and attestingWeight is summed over a continuous trailing window of recent blocks. Near-unanimity makes Liqua conservative: a malicious change needs almost everyone, which almost never happens by accident or attack.
// 98% of ATTESTING stake (continuous rolling window) — not 98% of all supply
const QUORUM = 0.98;                 // governed (and itself only changeable by 98%)
const WINDOW = 100_800;              // trailing blocks counted as "online/attesting"

function attestingWeight(t) {                       // continuous · recomputed each block
  return sum(activeLocks(t)
    .filter(L => L.lastAttest > t - WINDOW)        // only stake that showed up recently
    .map(L => veWeight(L, t)));                    // §2 ve-weight
}

function decide(proposal, t) {                       // proposal.kind ∈ ROLLBACK | CHANGE
  const q = proposal.approvingWeight / attestingWeight(t);
  if (q < QUORUM) return BE(hold, 'BELOW_98');
  return proposal.kind === 'ROLLBACK'
    ? BE(() => rollbackTo(proposal.block), 'R9_ROLLBACK_98')   // suspect block stays on chain as evidence
    : BE(() => applyChange(proposal.param), 'CHANGE_98');
}
DECISION (flag · liveness): "98% agree" is near-unanimous. If the denominator were all stake, a 2.1% holdout (or lost keys) could freeze every change forever. I made the denominator attesting stake in a continuous trailing window so absent/dead stake doesn't count — you keep 98% conviction without a permanent veto by the inactive. Alternatives if you prefer: (a) 98% of all supply (hard freeze, max safety); (b) 98% with a time-decayed quorum that slowly lowers if no quorum is reached. Tell me which.

Both powers route through the molecular META discipline: rollback is R9 (the bad block is kept as evidence, never deleted); the 98% threshold is the posture-pinned version of R12/R13's witness quorum.

§7 ▸ PRIOR ART · honest creditswe stand on shoulders
yearwhocontributionmaps to
2009Nakamotomonetary emission · decaying block subsidy§4 continuous decay
1999Castro · LiskovPBFT · K-of-N quorum tolerates bad actors§6 98% quorum
2013Laurie et al.Certificate Transparency · independent witnesses§1 SOMA proof · §6
2020Curve · Egorovvote-escrow (veCRV) · lock ≤4y for weight§2 ve-lock
2020O'Connor · Aumasson et al.BLAKE3 · parallel Merkle hash · derive_key/XOF§1 SOMA-256
2015Ethereum / Bertanikeccak-256 · the EVM boundary hash§1 EVM membrane
2002Yarvin et al.Urbit · deterministic personal OS from a seed§5 reward-in-instance
2019FIDO · W3CWebAuthn / passkeys · device-as-auth§5 R6 instance=auth
2021Unicrypt · Team.Financeliquidity lockers · proof-of-lock§3 locked-liquidity list
2024THE DREWLESS · 7SLFMOLECULAR CODING · the organism disciplinethe whole chain

The integration — emission + locking + governance + rewards expressed as one continuous molecular organism, hashed by a tree that is the stack — that is the Drewless contribution. None of the parts are new; the composition is.

§8 ▸ HONESTY · what this is and is not−PROD · DRAFT

Roadmap from here: reference SOMA-256 impl + vectors → ve-lock + locker EVM contracts → 98% governor → L2 getting-tool + confirmation oracle → the locked-liquidity dashboard (wired into liqua.html).

LIQUA CHAIN · v0.1 · −PROD DRAFT SPEC · CONTINUOUS · MIDNIGHT GRAPHITE
SOMA-256 · ve-LOCK ≤4y · LOCKED-LIQUIDITY LIST · CONTINUOUS EMISSION · REWARD-IN-INSTANCE · 98% GOVERNANCE ⨁ DREWLESS · 7-SLF ARCHITECTURE ◇ ⌬ OMNISOFT AI EXPERIENCE ▸ a MORE OR LESS PRODUCTIONS release