The PRANA Paper

The technical & consensus specification for PRANA — the community-owned AI-compute chain.

1 · Thesis & motivation

A community that wants an always-on AI can rent compute from a metered cloud — pay-per-token, revocable, owned by someone else — or own it outright. PRANA is the second choice, built as a blockchain so that ownership, payment, and verification of compute all live on one permissionless ledger. It is the engine room beneath the wider ecosystem: MELEK is the social layer (a Graphene chain), KULA is the DeFi economy, and PRANA is the compute-and-security base the other two settle against.

The goal is explicitly not to be a "mine-anywhere Etchash coin." Proof-of-work here is a thin security floor — enough to anchor ordering and liveness — while reward is meant to flow, over time, to useful work. Relative to honest peers: Bittensor scores intelligence via a subnet emission market; Akash / io.net are DePIN marketplaces renting GPU for fiat-priced leases; classic PoW pays purely for hashing. PRANA's contribution is to put HASH and TASK into one shared reward pot on a full EVM L1 — so a hashed share and a verified-work share compete for the same pot, and an ordinary Solidity economy is built on top. One chain that is at once a mining pool, a compute market, and a DeFi settlement layer.

2 · Consensus & chain parameters

PRANA is a core-geth fork — the maintained go-ethereum fork that kept Ethash proof-of-work after Ethereum's move to proof-of-stake removed mining from upstream Geth. PRANA runs its own genesis, so it is a fully independent chain that still keeps the entire Ethereum developer ecosystem (Solidity, OpenZeppelin, MetaMask, Hardhat/Foundry, Blockscout).

2.1 Pinned genesis parameters Pinned

Read directly from the sealed mainnet genesis and the forked client. Changing any of these is a hard fork.

2.2 Block time & emission Design intent

PRANA uses Ethash-style variable difficulty, so block cadence is emergent: the retarget converges toward the Ethash ~13–15 s band, but that is a target the algorithm aims at, not a header constant. Likewise, the live, pinned issuance is a flat 2 PRANA/block; a ~10%/yr geometric decay is the stated design direction but is not pinned — the client leaves a height-gated EthashBlockRewardSchedule as a documented extension that a hard fork would activate. Until then, block reward is constant.

2.3 Finality & reorg posture

As a Nakamoto/PoW EVM chain, PRANA has probabilistic finality: a block's safety grows with confirmations, and deep reorgs are possible but exponentially unlikely as work accumulates. There is no BFT instant-finality gadget. Value settlement — the bridge especially (§5) — should require a confirmation depth matched to the value at risk; thin early hashrate means shallower practical finality early on (§6).

3 · The see-saw — "the chain IS the pool"

This is PRANA's load-bearing mechanism. Instead of a block reward that pays only whoever sealed the block, PRANA runs one canonical mining pool pinned to the chain itself — the UnifiedSharesLedger — and pays a fixed per-epoch PRANA issuance pro-rata to everyone who credited shares into it during a rolling window. Three lanes credit into the same pot, each behind its own role-gated creditor:

Because all lanes draw from one pot, they see-saw: early on, with little AI demand, hash-shares dominate; as real AI-work arrives, task-shares grow and catch up — pulling reward toward useful work with no re-minting and no schedule change. Lane shares are pooled at a governed weight (HashTaskWeightConfig); the default HASH:TASK weight is 1:1, so a hashed share and a verified-task share earn identically — the "switching engine." Epoch boundaries are shared across every compute-stack contract via the EpochManager library so they never drift, and payout is PPLNS (pay-per-last-N- shares) over the trailing window, which smooths luck and discourages pool-hopping.

3.1 How TASK work is measured & attested

A forged TASK share would be worth a real HASH share, so verification is the make-or-break trust boundary, built from composable modules:

• TaskVerificationGate — a claim is "verified" only once K distinct staked-active attestors (a K-of-N quorum) attest it. Verdicts are one-shot consumed (credited exactly once) and credit is bound to the gate-recorded worker — a coordinator cannot redirect it.
• AttestationStakeSlash — attestors stake to be "active"; a SLASHER_ROLE slashes an attestor who signs off on bad work. Security is stake-at-risk, not trust.
• CoordinatorRegistry — "the chain IS the pool, but anyone may run a coordinator." Any operator can stand up a TASK-lane coordinator by posting a slashable bond; HASH-lane coordinators need no bond because a PoW share self-verifies.

Redundant recompute plus stake-slash is the anti-fabrication design: the cheapest way to earn the pot is to actually do the work.

3.2 Live compute-stack parameters

Live on mainnet (deployed 2026-08-29); governance-tunable, not consensus constants.

4 · The Hathor fee — consensus-level, un-bypassable Pinned

A fixed 2.00% (200 bps) of every block's gross issuance is routed, by consensus rule, to the HathorFeeTreasury rather than to whoever sealed the block — funding the community AI's upkeep. It is modeled on the Devcoin "receiver" pattern, made un-bypassable.

Why the consensus layer. An application-layer skim (there is also one — the SettlementFeeHook, taken inline at ledger payout) only bites when value is paid out of the on-chain ledger; a party running their own pool and settling off-chain could route around it. The consensus fee cannot be: it is applied inside AccumulateRewards, part of the canonical state transition. A miner who omits or short-pays it produces a different state root than honest nodes, so every validator's re-execution rejects the block as invalid. The fee is not "requested" — it is a block-validity rule. There is no PRANA in existence that did not already pay the fee at the moment it was minted.

• Launch-pinned. feeBps = 200 is a protocol constant; changing it is a hard fork. A future RateTransitions schedule is left as a documented extension.
• Governed sink, never a trader. The fee address is the HathorFeeTreasury contract, which never trades and only disburses under a DAO timelock. Its live address is on the deployed-contracts page so this paper cannot drift from the wiring.
• Two layers, not double-charged. The consensus fee is taken once, at issuance; the app-layer hook expresses the same idea inside the ledger payout path (rules-based, countercyclical rate) so the skim holds whether PRANA flows through our ledger or a pool we never wrote.

5 · Connection to the ecosystem

PRANA is the base coin; the economy on top is specified fully in the KULA Paper. In brief:

• The bridge (MELEK ↔ PRANA). MELEK (Graphene L1) locks value to mint wMELEK on PRANA via the GrapheneDepositBridge; burning wMELEK releases MELEK. A federated validator set (5 validators, 3-of-5) authorizes mints; the invariant is wMELEK supply == MELEK locked. The same wrapper pattern extends to wVKBT and wCURE.
• KULA / MWALI / APIS on top. KULA is the emission-only reward/DeFi token (cap 11M); MWALI is the proof-of-liquidity token; APIS is the MELEK-Engine fee token. The miner slice (45%) of KULA emission pays exactly the useful-work providers of §3 — the biggest reward slice points at the see-saw on purpose.
• Yield Farm & gauges. veKULA (lock KULA up to 4 years) boosts farm yield and directs, via the GaugeController, where new KULA emission flows.
• Forever-lock → APIS-Hash compute-mining tie-in. Wrapped MELEK bridged to PRANA can be forever-locked to mint soulbound APIS-Hash, a non-transferable mining-power unit that drips APIS forever — the BURN lane's economic hook into the pool. No debt, no liquidation.

6 · Roadmap, open questions & honest limitations

• Thin early liquidity & hashrate. A fair-launch chain starts with little market depth and low hashrate; low hashrate means cheaper theoretical reorgs and shallower practical finality early. Value settlement (bridge withdrawals especially) should use conservative confirmation depths until hashrate matures. The standard small-PoW-chain tradeoff, stated plainly.
• PoW security tradeoff by design. Keeping HASH "thin" is deliberate, but thin security still must be paid for; if TASK reward grows while hashing thins too far, the governed lane weights are the lever to rebalance.
• TASK-lane attestation maturity. The K-of-N staked-attestor gate is the trust boundary for useful work; its security depends on honest, well-staked attestor sets and on redundant recompute actually catching fabrication. This is the youngest, highest-risk part of the stack — the one most in need of adversarial testing and audit.
• Emission decay & fee-transition schedules are documented extensions, not shipped parameters (§2.2, §4) — each needs a hard fork to activate.
• Governance decentralization. Admin over the compute stack and fee treasury sits behind a DAO timelock; how distributed the keys and votes actually are is an ongoing process, not a finished state.

Open questions the design leaves to governance: the final HASH:TASK weight ratio, the emission-decay curve, per-task-type share weights, and the countercyclical fee schedule.

7 · Contract & chain reference

The deployed compute-stack addresses (UnifiedSharesLedger, HashLaneCreditor, TaskLaneCreditor, TaskVerificationGate, AttestationStakeSlash, CoordinatorRegistry, HashTaskWeightConfig, HathorFeeTreasury, SettlementFeeHook, and the bridge/KULA set) live on the deployed-contracts page and on Blockscout, so this paper points to the live registry rather than restating addresses that could drift.