Lode: fixed-supply mineable tokens on Solana

Lode issues tokens whose rules cannot be edited

A token launched through Lode fixes its supply, its emission schedule, its round length, its difficulty and its creator allocation in the launch transaction. There is no update instruction, no stored admin key and no setter that can widen a guardrail afterwards. The launched token has no administrator at all.

This is the product's only real claim, and it is a structural claim rather than a promise. The program contains no code path that could change a launched token's parameters, so keeping the claim true does not depend on anyone choosing to behave.

in plain languageprograms/lode/src/instructions/launch.rs · no admin exists after this returnsAGENTS.md · hard forbids

Proof of work here is a distribution mechanism, not a security mechanism

Solana provides consensus. The proof of work in Lode does not secure a chain and does not order transactions. It exists to make new supply cost something to obtain, and to make that cost payable by anyone with a browser rather than only by whoever runs the fastest hardware.

That framing is what allows fixed difficulty. A chain that used proof of work for security would have to retarget; a distribution mechanism does not.

in plain language

A share of a round is proportional, not competitive

Rounds do not have a winner. Every wallet that submits one accepted proof during a round is credited weight, and when the round closes its emission is divided across all of that weight in proportion.

Solving faster than another miner earns nothing extra. Solving at all is the entry condition; the size of the share comes from staked units, which is why a browser can compete with a datacenter for the same round.

in plain languageprograms/lode/src/round.rs · settle

Every launch opens its market in the same transaction

The launch transaction creates the mint, the fixed supply, the emission vault and the stake vault, then initializes the canonical Raydium CPMM pool for the mint against SOL in the same transaction: the pooled share of the creator allocation, at least half of it and chosen at launch, is paired with SOL the creator chooses, so the token has a price from its first second. The LP tokens and any kept share belong to the creator and are not locked, and nothing about launching here implies an aggregator listing or a verification badge.

The pool is created atomically with the mint because a canonical pool created any later can be front-run: on devnet, another party was able to initialize the canonical mint pair first, at an arbitrary price. A pool that exists before the mint is public closes that race by construction.

web/src/lib/solana/raydium.ts

Random payouts are excluded permanently

There are no jackpots, lotteries, prize draws or random bonuses, and none will be added. Consideration, chance and prize together are the gambling-law test, and a launchpad that meets that test in one jurisdiction meets it for every user in that jurisdiction.

This is recorded as a standing prohibition in the repository rather than a product preference, so that it survives a change of contributor.

AGENTS.md · hard forbids

No instruction accepts a token creator as a signer

LodeConfig records a creator public key. It is attribution and nothing else. No instruction in the program reads that field to authorize an action, and no account context requires it to sign.

A creator therefore has exactly the same authority over a launched token as any other wallet, which is none.

programs/lode/src/state.rs · LodeConfig::creator

Launch parameters are validated against fixed ranges, then frozen

The launch instruction rejects any parameter outside the ranges below. Because no admin exists afterwards, these bounds are the only protection against a launcher shipping absurd parameters, and they are compiled into the program rather than stored in a mutable account.

round length

30 to 3,600 seconds

halving interval

1,440 to 5,256,000 rounds

creator allocation

0 to 1,000 bps, and greater than zero base units

decimals

exactly 6

equihash

exactly n=96, k=5

base weight

exactly 0

name / symbol / uri

32 / 10 / 200 bytes

difficulty target

non-zero

in plain languageprograms/lode/src/state.rs · guardrail constantsprograms/lode/src/instructions/launch.rs · handler preamble

The creator allocation is capped at 10% and is displayed at full size

MAX_PREMINE_BPS is 1,000 basis points. The allocation is minted directly to the creator at launch, recorded on the config, emitted in the launch event, and required by the frontend specification to appear on the token page at the same size as every other fact.

Raising that ceiling requires an explicit recorded decision, not a code change alone.

MAX_PREMINE_BPS

1000

programs/lode/src/state.rs · MAX_PREMINE_BPS

The supply cap is structural at the token-program level

Launch mints the entire supply in one transaction, splits it between the creator allocation and the emission vault, and then revokes the mint authority. No freeze authority is set.

After that transaction, no further units of the token can be created by anyone, including the Lode program itself. The cap does not depend on Lode's own arithmetic being correct.

programs/lode/src/instructions/launch.rs · mint_to then set_authority

Metadata is immutable and is funded by the creator

A launched token carries a Metaplex fungible metadata account created as immutable. The launcher supplies a permanent metadata URI on Arweave, Irys or IPFS, which the browser fetches and checks before building the transaction: the document must carry the exact on-chain name and symbol and a content-addressed image.

Lode holds no storage credential and operates no upload proxy. The launch form has the creator pay Irys directly from their own wallet for permanent storage, then verifies the returned receipt and the stored bytes before building the transaction. A server-funded upload route was removed rather than left disabled, because a paid quota that anyone can call can be drained by callers who never launch.

in plain languageweb/src/features/launch/metadata.ts · pre-signature validationSTATE.md · frontend and clients

A version 2 config cannot be reinterpreted from legacy bytes

The stake model carries an account version, stored in the first byte of the region an earlier layout reserved. A legacy account therefore decodes as version zero, and every version 2 writer refuses it rather than reading old balance bytes as backed stake.

Legacy launch and mine are disabled. Legacy claim, crank and close remain available so that anyone holding a position under the earlier model can still exit it.

STAKE_MODEL_VERSION

2

programs/lode/src/state.rs · uses_stake_model

A round is a wall-clock interval, not a race to a solution

A round closes once round_seconds have elapsed since it opened. Hashrate does not shorten it and idleness does not extend it. The next round's boundary is advanced from the previous scheduled boundary rather than reset to the current time, so a token nobody has cranked for an hour catches up one round at a time instead of losing the schedule.

in plain languageprograms/lode/src/state.rs · round_elapsed, next_round_open_ts

Difficulty never retargets

Because the cadence is set by the clock, more hashrate cannot make rounds arrive faster, and there is nothing for a retarget to correct. The difficulty target is chosen at launch and is then fixed for the life of the token.

Difficulty here is a liveness bar rather than a race. It answers the question of whether a participant did real work this round; it does not decide who wins one. Equium, the project Lode derives from, retargets because its rounds end on a solution. That logic was deleted deliberately.

in plain languageprograms/lode/src/state.rs · module documentation

Emission halves on a fixed interval and is never stored

The reward for a round is computed as the initial reward right-shifted by the number of completed halving intervals, and it is computed on demand rather than cached. A stored current reward mutated at each boundary would be a second source of truth that can drift if a boundary is ever missed.

After 64 halvings the reward is zero.

halvings

(round_index - 1) / halving_rounds

reward

initial_round_reward >> halvings

in plain languageprograms/lode/src/state.rs · LodeConfig::reward_at

A schedule that cannot release the full allocation is rejected at launch

Launch sums all 64 integer right-shift tranches of the proposed schedule and fails if the resulting lifetime emission is smaller than the mineable allocation. A token whose arithmetic would strand supply in the vault forever cannot be created.

programs/lode/src/state.rs · scheduled_lifetime_emission

A round's budget is frozen when the round closes, and capped by the vault

The budget recorded for a closing round is computed against that round's own index, so a halving landing on the boundary cannot retroactively shrink work miners have already done. It is also clamped to the vault's remaining balance, so settlement can never promise more than exists.

Reserving the budget at close means cumulative_mined tracks what is owed rather than what has been transferred, which is what keeps the remaining figure honest for the next round's cap.

programs/lode/src/round.rs · maybe_close_round

One crank call advances exactly one round

The crank is permissionless and idempotent: calling it when nothing is due returns without touching state. It deliberately does not loop to catch up an idle token, because such a loop is bounded only by elapsed time and would exhaust the compute budget. The instruction is cheap enough to call repeatedly instead.

Mining requires a live round. A miner cannot roll the round forward inside their own submission, which would either verify against a challenge they did not solve or let them mine a historical round.

programs/lode/src/round.rs · maybe_close_roundprograms/lode/src/instructions/mine.rs · RoundElapsed guard

An empty round lapses

If no wallet submitted during a round, its budget is not reserved and not carried forward. The round is recorded as an empty tombstone and the emission for that interval is simply never released; the supply stays in the vault and the schedule continues from the next index.

programs/lode/src/round.rs · empty_rounds

Weight is program-custodied stake, and base weight is zero

A miner's weight for a round is exactly the number of the token's own units they have deposited into that token's stake vault and which are active. There is no per-wallet base weight and no wallet-balance snapshot.

Both alternatives were tried and rejected. A positive base weight lets one holder multiply their weight by splitting across free identities. A balance snapshot counts transferable units, which can be moved through a series of pre-warmed wallets and counted more than once.

DEFAULT_BASE_WEIGHT

0

in plain languageprograms/lode/src/instructions/mine.rs · weight = miner.active_stakeSTATE.md · rejected or deferred choices

A deposit activates in the following round

Deposited units land as pending stake with an activation round of the current index plus one, and are promoted to active stake only once that round exists. The units are in program custody the whole time.

The delay closes the atomic path in which a wallet borrows units, deposits them, mines, withdraws and repays inside a single transaction.

in plain languageprograms/lode/src/instructions/deposit_stake.rs

Stake that weighted an unsettled round cannot be withdrawn

Withdrawal requires the miner to carry no unsettled round weight. If the wallet submitted a proof in a round that has not yet been settled, the whole position is locked until it settles, not just the portion that was counted.

The simple whole-position rule is deliberate. A partial rule would let principal move to a second wallet while it is still present in the first wallet's numerator for a round that has not paid out.

in plain languageprograms/lode/src/instructions/withdraw_stake.rs · StakeLocked

Settlement is pro-rata and truncates toward the vault

A miner's share of a closed round is the round's budget multiplied by their credited weight, divided by the round's total weight, computed through a 128-bit intermediate and truncated to an integer.

Truncation always favours the vault: the sum of integer-divided shares can never exceed the budget, so a round cannot pay out more than it reserved. The remainder is not redistributed and not rounded up. Doing either would create a path that overdraws the vault.

share

budget * weight / total_weight

in plain languageprograms/lode/src/round.rs · settle

Settlement history is a bounded ring of 32 rounds

A round's total weight is only known once it closes, so a miner settles their share on their next action rather than at the moment of submission. The closed rounds available to settle against are held in a fixed 32-slot ring inside the config account.

A slot resolves only when the round number stored in it equals the round being asked for, so a round that has been lapped stops resolving instead of returning a newer round's numbers. Round zero never enters the ring, because a zeroed slot would otherwise read as a real entry.

At a 60-second cadence the ring covers roughly 32 minutes. A miner who acts every round always settles; one who walks away for longer forfeits the unsettled tail. The alternative, one account per round, costs rent per token that grows without bound.

ROUND_RING

32

programs/lode/src/state.rs · ring_slot, ROUND_RING

Direct transfers into a stake vault are uncredited donations

Only a deposit instruction increases total_staked or any miner's credited principal. Tokens sent directly to the stake vault address raise the vault balance without raising anyone's claim on it.

The accounting invariant this preserves is that the sum of credited stake equals total_staked, which is less than or equal to the vault's actual balance. Liabilities stay bounded by assets in every case, including the donation case.

programs/lode/src/instructions/deposit_stake.rs

Claiming is separate from mining and from withdrawing

Mining accrues weight and never moves tokens. Claim moves settled rewards from the emission vault. Withdraw returns principal from the stake vault. The two vaults are distinct accounts, so a claim can never consume withdrawable principal.

Claim also cranks and settles on the way through, so a miner who has stopped mining can still collect the last round they worked without waiting for anyone else to act.

programs/lode/src/instructions/claim.rs

The input block binds the mint and the miner

The Equihash input block is 113 bytes: a 9-byte personalization string, the mint, the current challenge, the miner's public key, and the round index as a little-endian 64-bit integer.

Binding the miner's key defeats front-running, because a copyist would have to re-sign under their own key, which produces a different input block and invalidates the solution. Binding the mint defeats cross-token replay: many tokens share one program, and without the mint a solution valid for one token would be valid for another whenever their challenge and round index coincided.

This construction exists in exactly one place and must stay byte-identical on-chain, in the CLI and in the browser miner. A test asserts that changing the mint changes the input block.

I

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

PERSONALIZATION

"Lode-v1.0", 9 bytes

I_LEN

113 bytes

in plain languagecrates/equihash-core/src/challenge.rs · build_inputprograms/lode/src/pow.rsclients/web-miner/wasm/src/lib.rs

The challenge chain is unpredictable before a round opens

Each new challenge is the SHA-256 of the mint, the previous challenge and a slot hash read from the SlotHashes sysvar at the slot the round opens. Because that slot hash does not exist until the round opens, nonces cannot be precomputed for a future round.

A token's genesis challenge is derived from the mint and the launch slot hash, with no launcher-supplied input, so a genesis challenge cannot be chosen to collide with a live token's current challenge.

next

sha256(mint || prev_challenge || open_slot_hash)

genesis

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

crates/equihash-core/src/challenge.rs

One accepted solution per wallet per round

A wallet that has already been credited weight in the open round is rejected if it submits again. Without this rule a miner could resubmit repeatedly to inflate their weight, which is the dynamic that turns a mining program into a transaction-spam auction.

Combined with weight being staked units, repeated solving and wallet splitting both change nothing: splitting a position across two wallets produces two submissions whose weights sum to the original.

programs/lode/src/instructions/mine.rs · AlreadySubmitted

A submission with zero active stake is rejected

Verification of the proof happens first, but weight is read afterwards, and a miner whose active stake is zero cannot submit. Solving alone does not enter a wallet into a round.

programs/lode/src/instructions/mine.rs · StakeRequired

Solving runs in the browser as WebAssembly

The solver is compiled from the same Rust crate the program verifies with, and runs in a worker so the interface stays responsive. Missing a round is normal and is reported as a missed round rather than as an error.

Verification of one submission was measured at 219,715 compute units on the version 2 instruction. Clients request a 300,000-unit limit.

measured mine_v2

219,715 CU

in plain languageclients/web-miner/wasm/src/lib.rsweb/src/features/mine/solver.worker.ts

Every account except the platform is seeded by the mint

A token's configuration, emission vault, stake vault and per-wallet miner accounts are all program-derived addresses that include the mint in their seeds. Two tokens can therefore never share state, and an account belonging to one token cannot be passed into an instruction operating on another.

config

["lode-config", mint]

emission vault

["lode-vault", mint]

stake vault

["lode-stake-vault", mint]

miner

["lode-miner", mint, authority]

platform

["lode-platform"], singleton

in plain languageprograms/lode/src/state.rs · PDA seeds

Cross-token replay is closed at both ends

The mint is inside the input block, so a proof produced for one token hashes to a different value under another. The mint is also inside the challenge derivation, so two tokens whose challenge chains ever coincided diverge at the next round instead of remaining in lockstep.

Isolation and replay rejection are both covered by the compiled-program integration suite rather than by unit tests alone.

crates/equihash-core/src/challenge.rstests/ · tenant isolation, cross-token replay

Round history costs no additional accounts

Holding settlement history inside the config's fixed ring, rather than as one account per round, means a token's history costs no rent beyond the config account itself, at any age and at any number of miners.

The cost of that choice is the bounded window described in the settlement clause, and it is the intended trade.

programs/lode/src/state.rs · ROUND_RING rationale

The platform singleton holds the only live authority

One platform account stores an authority key, a fee recipient and two flat lamport fees. It can be initialized only by the deployed program's current upgrade authority, and it may assign a separate operational authority distinct from that upgrade key.

The current instruction set can change the two fees but has no path to rotate the authority or recipient. Program upgrades remain possible, so this is a property of the selected release rather than an upgrade-proof guarantee. The platform account cannot alter a launched token's supply, emission, difficulty, round length or creator allocation.

programs/lode/src/state.rs · Platformprograms/lode/src/instructions/init_platform.rs

Every fee is bounded by a maximum the user signs

Launch and mine both take a maximum fee parameter and fail if the live platform fee exceeds it. A fee raised between the moment a transaction is built and the moment it lands causes that transaction to fail rather than to charge more than the signer agreed to.

The mine fee is charged per instruction rather than per transaction, so packing many miners into one transaction saves nothing.

programs/lode/src/instructions/mine.rs · PlatformFeeExceedsMaximum

The release config names the initial fees and selected roles

The release config sets 300,000,000 lamports per launch and 10,000,000 lamports per accepted mine. Both are live: the mainnet platform singleton was initialized with exactly these values, checked against the manifest before the transaction was sent.

One wallet controls program upgrades and platform fees, and a second receives the fees. Both keys are held by one operator, so a compromised operator would expose every role. The current program has no role-rotation instruction, while an upgrade could change that behavior. Fee-charging instructions still cannot exceed the maximum the user signs.

launch fee

0.3 SOL

mine fee

0.01 SOL

authority

3nPXHv...cLZZi

fee recipient

E7DpAv...G5zpJ

release/mainnet.json

Chain state is authoritative and there is no indexer

The app reads Lode, SPL Token and Metaplex accounts directly over RPC and refreshes them from program subscriptions. No database, no indexing service and no backend cache sits between the program and what the page displays.

Where a value is genuinely unknown, the interface renders it as unknown rather than as a zero or a dash that could be mistaken for a real figure.

web/src/lib/solana/reads.ts

The wallet cannot change what a transaction does

The client compiles and simulates each transaction before signing. It normally requires the wallet to return the same message under the same blockhash. Phantom may insert Lighthouse assertions and raise the compute-unit limit to cover those checks. The client accepts only those assertions and a limit increase no higher than Solana's 1.4 million CU cap. The compute-unit price, planned programs, accounts, privileges, data, signer set and fee payer must remain unchanged. The signature, lifetime and typed receipt persist before broadcasting.

An unresolved transaction survives a page reload: the client searches status history through expiry and acknowledges the action only after authoritative state has been re-read. A browser-wide exclusive lock prevents two tabs from signing at once.

web/src/features/transactions/pipeline.tsweb/src/features/transactions/recovery.ts

Wallets that cannot return a signed transaction are not offered

Wallet discovery requires the solana:signTransaction feature. Sign-and-send-only wallets are hidden rather than shown and then failed, because the executor cannot verify what such a wallet actually broadcast.

Lode never generates, imports, exports or stores a private key in the browser.

web/src/lib/solana/wallet-capabilities.ts

A wallet is an authorization key, not an identity

Nothing in the reward model treats one wallet as one person. There is no per-wallet bonus, no proof of personhood and no attempt to detect a wallet split, because every such attempt is defeated by generating another keypair.

The model is built so that splitting is neutral rather than penalized.

The release program is live on mainnet

Lodeq5vB is deployed on mainnet-beta. The finalized on-chain bytes reproduce the reviewed release artifact hash exactly, the platform singleton is initialized with a 0.3 SOL launch fee and a 0.01 SOL mine fee, and the program upgrade authority was transferred to the platform authority in the same transaction that initialized it.

The same program is also deployed on devnet, where the full acceptance path was run before mainnet. The AB6LW5 program still on devnet hosts an earlier build and already-initialized legacy platform roles; it is separate and superseded.

release program id

Lodeq5vBgbirxzXiCbEeXjRYmjXdWvXgxzunyiwgMJC

program sha-256

87223745e93c15d917c2fc4270c4003abb0bb146280deea8ad721ff4bba47ecd

legacy devnet program

AB6LW5ccieBFVqXVLiLFTuQ84tAbPuefXSNHJJuNBmJg

in plain languageSTATE.md · cluster state

Local verification that has been run

The workspace host tests, the compiled-program integration suite and the web checks all pass on the current local source. The integration suite covers two tokens, two wallets and three weighted rounds with exact balances, plus replay isolation, cycling prevention, wallet splitting, donations, ring eviction, legacy gates, metadata and fee ceilings.

The exact release bytes also passed the deployed acceptance path twice: against a local validator, then against the public devnet deployment, where all 83 logged transactions finalized and terminal liabilities were zero. The pinned container build has reproduced the release hash bit for bit on two separate runs. An independent program review and an independent review of the web transaction path each found no remaining high-severity findings in their reviewed scopes.

host tests

equihash 12, program 17, wasm 1

cli tests

7

integration

24 against the compiled program

web tests

93, plus lint, typecheck and build

program sha-256

87223745e93c15d917c2fc4270c4003abb0bb146280deea8ad721ff4bba47ecd

in plain languageSTATE.md · verification

What is not proven

The deployed acceptance path, the container-build reproduction and the real wallet browser path have all completed, on devnet, against the exact release bytes. Mainnet is younger: the program is deployed and tokens have launched, but a complete mainnet stake, mine, claim and withdraw cycle has not yet been observed.

Also outstanding: the container build has not been repeated by remote CI, the source repository is not yet public, and no external security firm has been commissioned. The program is live on mainnet without an external audit; weigh that yourself.

in plain languageTASKS.md · release blockers

Not built

The following are named because people ask about them, and each one is absent from the current build rather than planned for a date. No timeline is attached to any of them.

Liquidity locking. Every launch creates a Raydium pool, but the LP tokens stay with the creator rather than being locked or burned. Aggregator routing and token verification are outcomes decided by third parties and will not be promised here.

Also absent from version 1 by decision: charts, leaderboards, search, referral ladders, duration boosts, a GPU miner, an indexer, and embedded custodial wallets.

TASKS.md · deferred, out of scope

Derived from Equium, under Apache-2.0

Equium implements a single fixed CPU-mineable token. Lode converts that design into a multi-tenant launchpad. The licence is Apache-2.0, inherited, and the NOTICE file carries the statement of changes that section 4(b) of that licence requires.

Files carrying substantive edits are marked in their header comments, so the boundary between inherited and new work stays inspectable rather than asserted.

upstream

github.com/HannaPrints/equium

licence

Apache-2.0

NOTICELICENSE

The structural changes from Equium

Singleton accounts became per-mint accounts. Compile-time emission constants moved into per-token configuration chosen at launch and frozen. A single launch instruction replaced a deployer-run initialize plus off-chain mint creation. Equium's admin key and its optional renounce step were removed entirely rather than made optional.

Rounds became time-boxed and pro-rata rather than ending on a solution with one winner, difficulty retargeting was deleted, weight became program-custodied stake, and the token mint was bound into the Equihash input block.

NOTICE · statement of changes

The source is not published yet

Repository paths are cited throughout this paper so that each claim points at the file that has to be read to check it. Those paths are not links, because no public repository has been configured yet.

Until it is, the honest position is that the claims in this document are checkable by whoever holds the source, and not yet by the public.

TASKS.md · release blockers