the proof of work

Solana already provides consensus. The hashing here does not secure a chain and does not order anything. It exists so that new supply costs something real to obtain, and so that the cost is payable from a laptop rather than only from a rack. §1.2

That is why the difficulty is a liveness bar and not a race. A round asks each participant whether they did work, once, and then divides the emission by stake. Nobody wins a round.

The Equihash input block is 113 bytes and identifies exactly one token, one miner and one round. Both bindings do specific work. §5.1

I

PERSONALIZATION || mint || challenge || miner || round_index_le

personalization

"Lode-v1.0", 9 bytes

field widths

9 + 32 + 32 + 32 + 8 = 113

algorithm

Equihash n=96, k=5

accepted when

sha256(indices || I) <= target

The miner's public key is in there so a solution cannot be copied out of the mempool and submitted by someone else: a copyist would have to re-solve under their own key, which changes the input and invalidates the work.

The mint is in there because one program hosts many tokens. Without it, a solution valid for one token would be valid for another whenever their challenge and round index coincided, and a launcher able to influence their own genesis challenge could force that collision on purpose. With the mint bound in, every token has a disjoint solution space by construction. §6.2

Each round's challenge is derived from the mint, the previous challenge and a slot hash read at the moment the round opens. Because that slot hash does not exist until the round opens, nonces cannot be precomputed for a round that has not started. §5.2

next challenge

sha256(mint || prev_challenge || open_slot_hash)

genesis challenge

sha256("lode-genesis" || mint || launch_slot_hash)

A launcher supplies no input to their genesis challenge, so it cannot be chosen to collide with a live token's current challenge. Cross-token replay is closed at both ends: at the input block and at the challenge chain.

A token's target is set at launch and is then fixed for its whole life. There is no retarget instruction and no admin who could add one. §3.2

Retargeting exists on chains whose block interval depends on hashrate. A Lode round ends on the wall clock, so hashrate cannot change the cadence and there is nothing for a retarget to correct. Equium, the project this is derived from, does retarget, because its rounds end when someone solves. That logic was removed on purpose.

The solver is compiled to WebAssembly from the same Rust crate the on-chain program verifies with, and runs in a worker so the page stays responsive. On-chain and off-chain construction of the input block must stay byte-identical, which is why it exists in exactly one file and is guarded by a test. §5.5

measured verification

219,715 compute units

requested limit

300,000 compute units

keys in the browser

none, ever