LithosDocs
ProtocolPayoutsTokenStatsDocs
Start mining
Documentation home
Protocol
  • Lithos Protocol
  • LFSM
    • Rollups
    • NISPs
    • Emissions
    • Mining on Lithos
    • Candidate building
    • Ergo Voting
  • LithosDex
    • Trading with orders
    • Providing liquidity
Run Lithos
  • Startup guide
    • Setting up an Ergo testnet node
  • Configuration
    • Node connection and security
    • Stratum and difficulty
    • Block packages
    • Batching and orders
    • Collateral and emission
    • Wallet and consolidation
    • Statistics and web panels
    • Synchronization and storage
    • Tasks and dispatchers
    • Failure modes
    • Reporting issues
Client API
  • Overview
    • getLithos client information
    • getList UTXO ids for blocks
    • getUTXO ids by block height
    • getBlock info by UTXO id
    • postBlock info for multiple UTXO ids
    • getGet a block's miner set
    • getList all pool blocks
    • getGet Lithos payouts
    • getStatistics overview
    • getMining and payment totals
    • getMining statistics by hour or day
    • getEstimate Lithos hashrate
    • getNetwork difficulty by epoch
    • getThis client's own hashrate
    • getThis client's hashrate over time
    • getThis client's payouts and claims
    • getCollateral inventory
    • getLocal mining activity
    • getCollateral market snapshot
    • getList queue boxes
    • getList the active set
    • getPermit price history
    • getYour locked block rewards
    • postClaim unlocked block rewards
    • postQuote joining the queue
    • postJoin the collateral queue
    • getLithosDex pool state
    • getLithosDex fee vault state
    • getList your outstanding orders
    • postQuote a swap order
    • postPlace a swap order
    • postQuote a deposit order
    • postPlace a deposit order
    • postQuote a redeem order
    • postPlace a redeem order
    • postCancel an order
    • postQuote a swap
    • postQuote a swap by desired output
    • postExecute a swap
    • postQuote a liquidity deposit
    • postDeposit liquidity
    • postQuote a liquidity redemption
    • postRedeem liquidity
    • getList liquidity provisions
    • postClaim settled fees for a provision
    • postQuote a provision resize
    • postResize a provision
    • postCheck a pending fee flush
    • postFlush pending fees to the vault
    • getPool-wide fee history
    • getPool price history
    • getRecent pool activity
    • getFee history for one provision
    • getWallet balances and lending status
    • getGet Stratum information
    • getGet candidate settings
    • getGet difficulty commitment
    • postCommit a difficulty
    • getGet best NISP at height
Lithos

A decentralized mining pool protocol on Ergo. Miners build their own blocks; contracts pay them for proven work.

Live on Ergo mainnet
Protocol
  • How Lithos works
  • Mining on Lithos
  • NISPs
  • Emissions
  • LFSM contracts
Run Lithos
  • Startup guide
  • Configuration
  • LithosDex
  • Client API
  • Failure modes
Network
  • Live stats
  • Public stats API
  • Ergo Platform↗
  • SOAT Miner↗
Community
  • Telegram↗
  • X / Twitter↗
  • GitHub↗
Lithos
© 2026 Lithos Protocol. Open source under the MIT licence.λίθος — stone
Docs/Run Lithos/Configuration

Collateral and emission

Driving the collateral queue, and putting your own ERG and LIT into it.

Advanced6 min readAssumes you have read how collateral and the permit work in Lithos Protocol.

The emission block covers two different jobs that share a timer. The first is driving the queue, which every client does and which costs only transaction fees. The second is joining the queue with your own funds, which locks ERG and LIT until a miner spends the box, and which ships off.

This is maintenance that runs whether or not you ever mine a block.

Danger
A queued position cannot be withdrawn

Once your ERG and permit are in the queue, neither returns until a block spends the box. There is no cancel path, by design. Everything under Lending your own funds is a commitment rather than a setting you can back out of.

Driving the queue#

SettingDefaultRangeWhat it does
emission.enabledtruetrue or falseDrive the collateral queue at all
emission.queueInterval2400001000 to 3600000 msHow often to look at the head of the queue
emission.maxQueueSpends41 to 128Emission spends chained in one pass, which is how deep into the queue a pass reaches
emission.queueScanLimit5001 to 100000Queue boxes paged through when looking for the head
emission.txFee1000000The network minimum fee to 1000000000 nanoERGFee on emission transactions

Activating the head of the queue turns a waiting position into a live collateral box, which is what keeps collateral boxes available for everyone to mine against. Clearing removes a box whose lender key is already active and which would otherwise hold the whole queue still.

Both are permissionless, and clients are encouraged to keep this on so that pool liveness is mainained.

txFee is floored at the network minimum because a transaction below it will not relay.

Queue work in your own blocks#

When you mine with inserted transactions on, your block also carries queue spends without a fee, built from the confirmed chain. The following setting caps them:

SettingDefaultRangeWhat it does
emission.candidateActivates50 to 100Activates your block carries when there is no Clear to take

What your block carries depends on what is already waiting in the mempool, as the following table shows:

Waiting in the mempoolYour block carries
No queue spendActivates up to candidateActivates, for one block. A block later the queue pass sends them with a fee instead
Anything, with a Clear within reachEvery queue spend up to the emissions source's maxTxs, replacing what is waiting
Only joinsNothing. The queue pass runs straight away, so its Activates follow the joins
Other queue spendsNothing. Your node adds the waiting ones to the block itself

A Clear pays whoever builds it the forfeited queue box, about 2.9 ERG plus its permit. That is why your block takes one even when another client has already sent theirs. Joins waiting in the mempool are left out of that block, and their clients send them again. Nobody's principal is at risk.

While the active set is still filling, each Activate takes about 7 KB of your block. That is why candidateActivates sits below the emissions source's maxTxs of 20, which Clears may fill.

Chaining off the mempool#

The following setting decides how far a queue pass looks into the mempool:

SettingDefaultRangeWhat it does
emission.maxChainDepth160 to 4096Unconfirmed spends of the emission box to follow

Queue passes always build on the newest emission box, confirmed or not. Following the unconfirmed spends behind it is what lets a pass activate queue boxes that joins still in the mempool created. Boxes further along the chain are not seen until they confirm.

The unconfirmed spends being chained onto belong to other lenders. A queue pass chains onto them and never replaces them in the mempool.

Lending your own funds#

SettingDefaultRangeWhat it does
emission.autoCollateralizefalsetrue or falsePut your own ERG and LIT into the queue
emission.collateralizeInterval9000001000 to 86400000 msHow often to check whether more collateral is wanted
emission.maxJoinsPerRun51 to 128Queue boxes created in one pass
emission.maxOwnCollateral100 to 2000Your boxes live at once, across the queue, live collateral and the active set
emission.maxLenderKeys321 to 1000, and at most node.numAddressesWallet addresses dedicated to lending
emission.maxPermitPerJoin40000000000000Any positive value, in LIT base unitsThe most LIT to post as a permit on one box
emission.priorityFeeNanoErgs00, or 1000000 to 3000000000 nanoERGERG each position adds above the 2.915 ERG floor, to be spent sooner

What a position costs#

Each live box locks 2.915 ERG plus its permit until a miner spends it. So maxOwnCollateral is your total exposure ceiling, not a throughput setting: at the default of 10 you can have about 29 ERG plus ten permits committed at once.

maxPermitPerJoin is a price you are willing to pay, not a fee. The permit rises with the queue backlog, from a floor of 2,000 LIT toward a ceiling of 40,000. When the thermostat passes your cap, the run stops rather than paying it. The default is the protocol ceiling itself, so out of the box price never blocks a join.

The value is in base units at 9 decimals, so 40,000 LIT is 40000000000000.

Paying for priority#

A miner who finds a block spends the collateral box that pays them most, so a position that offers more is spent ahead of the ones that offer nothing. priorityFeeNanoErgs is that offer, for the positions autoCollateralize creates. A join from the web panel sets its own. Each position then locks 2.915 ERG + priorityFeeNanoErgs, and when a miner spends it the fee divides as follows:

ShareGoes to
One fifthThe miner who spends the box
Four fifthsThe rollup that block opens, paid to every miner who submits to it

Because transaction fees in a Lithos block go to the lender, paying for priority works like a fee future: you pay to be spent sooner, for example when you expect the blocks ahead to carry high fees.

A position that offers nothing is still spent eventually. Miners running this client draw any box that has been live for 7200 blocks, about 10 days on mainnet, ahead of every priority fee. Each miner can change that age with stratum.candidate.clearanceAge, so treat it as typical rather than guaranteed.

0 posts at the floor and offers nothing. Any other value must be at least 1000000 (0.001 ERG), so the miner's fifth is worth more than the output it arrives in.

Warning
Past 0.085 ERG the block reward no longer covers your principal

The lender receives the 3 ERG block reward plus the block's transaction fees. Above 85000000 (0.085 ERG) the priority fee takes the principal past 3 ERG, so getting it all back depends on the fees in the block that spends your box. The client allows it, and logs a warning on every self-collateralization pass that posts above this.

One key per box, and why it matters#

The active set holds distinct keys. One live box needs one address, and a key already in the set produces a box nobody can activate.

Danger
A reused lender key forfeits the whole box

A queue box whose key is already active can only be cleared, and clearing forfeits both the principal and the permit to whoever builds the clearing transaction. This is why maxLenderKeys may not exceed node.numAddresses, and why the client refuses a manual join while autoCollateralize is on: the automated pass owns key selection and a manual join could take a key it is already using.

Startup checks the pair and names the value to raise:

emission.maxLenderKeys
    64 exceeds node.numAddresses (32). Addresses past index 31 would receive funds this
    client cannot sign for. Raise node.numAddresses to at least 64

Next steps#

  • Wallet and consolidation: where the ERG for these transactions comes from.
  • Node connection and security: node.numAddresses, which caps your lender keys.
Edit this page on GitHubsynced from e0ca86a
← PreviousBatching and ordersNext →Wallet and consolidation
On this page
  • Driving the queue
  • Queue work in your own blocks
  • Chaining off the mempool
  • Lending your own funds
  • What a position costs
  • Paying for priority
  • One key per box, and why it matters
  • Next steps