XBT Lazarus-Auszahlungen im Überblick: 332 Transaktionen und 366.7 XBT in der Warteschlange
Lazarus Pool has started paying miners who were left out of the coinbase split on certain earlier XBT blocks. The pool calls these payments make-goods. They are not a bonus and they are not a new network-wide XBT withdrawal freeze. They are delayed compensation for mining rewards that should have reached miners directly when the original blocks were found.
The public queue is large enough to deserve attention: about 366.7 XBT remained scheduled across 332 records at our last check. But the important story is not simply the total. It is how a gateway limitation turned a coinbase-direct payout system into a temporary pool liability, how Lazarus is resolving it, and what miners should verify before pointing more BLAKE2b hashrate at any DATUM pool.
What Is an XBT Make-Good Payout?
Under Lazarus’s normal DATUM setup, the block coinbase is divided among eligible miners. This lets a miner receive an on-chain output from the block itself instead of waiting for the pool to hold and later withdraw the balance.
Some older gateway builds did not always construct that full split correctly. Lazarus identifies two affected cases:
- Partial coinbase: the block paid some of the intended miner outputs, but not all of them.
- Pool-only coinbase: the block paid the pool output but included no direct miner payouts.
The miners’ shares were still recorded. Once the pool-controlled coinbase output becomes spendable, Lazarus signs a separate on-chain transaction that pays the omitted miners. That later transaction is the make-good.
This distinction matters. The underlying shares were not erased, and the make-good is not a discretionary airdrop. It is settlement of an amount the pool’s records already attribute to the miner.
Why Did the Coinbase Split Fail?
The clearest technical explanation is in the DATUM BLAKE2b StartOS package documentation. Gateway versions through 1.0.0:52 inherited coinbase-size classes designed around other mining hardware. BLAKE2b ASICs could fall into a 750-byte class that allowed only about 17 payout outputs.
That ceiling was far below the number of miners that Lazarus might need to pay in one block. The package documentation describes a Lazarus payout window of roughly 440 miners. When the constructed coinbase could not carry the full payout list—or when a miner used the pool-only job path—the pool received value that would otherwise have been split directly.
The current package documentation says build 1.0.0:53 moved BLAKE2b mining to the full payout path, supporting a coinbase up to 32,000 bytes and as many as 1,024 outputs. Lazarus has also published a BLAKE2b unsplit-coinbase advisory explaining the affected behavior.
Miners should still use the build currently recommended by the pool rather than treating one version number in an article as permanent. Gateway software and pool requirements can change.
What the Public Queue Shows
| Metrisch | Snapshot at height 979,900 | Was es bedeutet |
|---|---|---|
| Queued make-goods | 332 records / 366.71809716 XBT | Waiting for their parent coinbase outputs to mature |
| Bereits bezahlt | 46 records / 70.72911462 XBT | Broadcast and recorded as completed by the tracker |
| Gescheitert | 0 records | No tracker failures at the time checked |
| First / last queued maturity | 980,119 / 986,289 | The queue clears progressively, not in one payment event |
| Recorded custody fees | 0.29017851 XBT | Adjustment tied to affected outdated gateways, not a fee on every miner |
The tracker also exposes the original block, maturity height, payout amount, status and transaction ID for each record. That is useful operationally: miners can verify a claim against the chain instead of relying only on a Discord announcement or an internal pool balance.
The 332 queued records were scheduled from block 980,119 through 986,289, a span of 6,170 blocks. At the network’s ten-minute target, that is roughly 43 days. Actual calendar timing depends on block production.
Is Lazarus the Only XBT Pool Exposed to This Risk?
Lazarus is the only XBT pool we found publishing a quantified make-good queue with individual records, amounts, maturity heights and transaction IDs. That does not mean the underlying gateway problem was unique to Lazarus. Other DATUM pools document the same coinbase-capacity failure mode, but they prevent, carry forward or settle omitted payouts in different ways.
| Pool | Normal payout design | Dokumentierte Handhabung | Nachweisstatus |
|---|---|---|---|
| Lazarus | DATUM/TIDES, paid in coinbase | Separate on-chain make-good transaction after the affected pool output matures | Confirmed live compensation queue |
| Omega Pool | DATUM, paid in coinbase | Warns that ratum-gateway versions before 0.1.23 may cap the split at about 17 outputs, leaving the operator to settle the remainder manually | Same technical risk documented; no public queue total found |
| B2Pool | TIDES, normally paid in coinbase | If the payout split cannot be fetched, that block pays the pool address and is settled later from the pool wallet | Published fallback design; no public backlog found |
| Rabid Pool | DATUM/PPLNS, paid in coinbase | Says its gateway fits 50–60+ payouts while stock gateways fit about 10; unpaid portions carry into later blocks, and NoSplit work can be refused instead of mis-paid | Capacity issue acknowledged; handled differently from Lazarus |
| AlphaPool | DATUM/TIDES, paid in coinbase | Erfordert blockmaxweight=740000 to reserve room for the payout list; its published blocks show large multi-output splits |
No public make-good backlog found |
| Bitcoin Xor | DATUM/TIDES, paid in coinbase | Supports maintained RATUM or CONVOY gateways and publishes the coinbase payout records | No public make-good notice found |
This comparison should not be read as an accusation that every DATUM pool owes miners money. It shows that coinbase-direct pools need an explicit answer to the same operational question: what happens if a gateway cannot fit or retrieve the complete payout split?
Conventional PPLNS or FPPS pools are different. They normally receive the block reward into a pool-controlled wallet and later pay miner balances. A truncated direct-coinbase split is therefore not their main failure mode; miners instead take ordinary pool-custody, withdrawal and solvency risk.
Why the Make-Goods Wait About 45 Days
The affected blocks were mined during XBT’s earlier 6,480-block coinbase-maturity window—approximately 45 days. Lazarus cannot spend the pool coinbase output before it matures, so it cannot broadcast the compensation transaction early.
This is separate from the newer XBT 180-day mining reward rule, which applies to new coinbase outputs from height 979,919. The queued make-goods do not restart a second 45-day or 180-day coinbase clock when they are paid. They are ordinary transaction outputs created after the parent coinbase becomes spendable.
For the history and implications of the earlier rule, see our XBT 45-day reward-lock analysis.
Who Pays the 10% Custody Adjustment?
The 10% adjustment is easy to misread. Lazarus does not describe it as a blanket fee on every make-good or every pool user. The pool’s advisory and public pool listings tie it to miners whose own outdated gateway creates an unsplit or pool-only coinbase, forcing the pool to custody and later redistribute funds.
The public API says the policy applies from height 977,665. The practical message is simple: if a miner continues using a gateway known to produce the faulty payout path, the miner can bear part of the extra custody and transaction burden. Miners who were omitted because of someone else’s block construction should not assume the same deduction applies to them.
If your expected amount and the tracker amount differ, check the original block, your payout address, the gateway version that found the block and the pool’s current policy before drawing a conclusion.
Is 366.7 XBT a Market Risk?
The queue is meaningful to affected miners, but it is not a single 366.7 XBT unlock. Payments become eligible block by block over several weeks. At a nominal subsidy of 3.125 XBT per block and about 144 blocks per day, the network creates roughly 450 XBT of mining rewards per target day. The queued total is therefore less than one nominal day of new miner supply.
That comparison does not prove there will be no price impact. XBT liquidity can be thin, recipients may sell to cover delayed power bills, and actual block intervals vary. It does show why describing the queue as an imminent one-time dump would be misleading. The more relevant risks are gradual sell pressure, poor order-book depth and the cash-flow strain already carried by the affected miners.
What This Says About “Non-Custodial” Mining Pools
Coinbase-direct payout design reduces pool custody in normal operation, but it does not remove software risk. The miner, gateway, template provider and pool accounting system all participate in producing and attributing the block. If the gateway builds the wrong coinbase, value can still land under pool control and create an IOU-like obligation.
Lazarus’s response has two positive signals: the liability is publicly itemized, and the settlement process is visible on-chain. The API showed no failed records at our check. That is stronger than an opaque promise.
The incident still exposes a governance question. A direct-payout pool needs clear version requirements, rapid alerts for faulty templates, independent reconciliation and a published recovery policy. “Non-custodial” should describe the normal value flow, not be treated as a guarantee that custody can never arise.
Was XBT-Miner jetzt tun sollten
- Check your payout address. Suche das live make-good data and record the original block, amount, maturity height, status and transaction ID.
- Verify the gateway build. Compare your installed version with Lazarus’s current setup instructions and update if it uses the affected payout path.
- Do not count queued XBT as spendable cash. Budget power and hosting until the parent coinbase matures and the make-good transaction confirms.
- Keep logs and payout records. Preserve the gateway version, miner address, pool response and block details in case the expected amount differs.
- Test a fallback. BLAKE2b ASIC owners can maintain a verified Siacoin configuration so an XBT pool or node problem does not stop the entire farm.
- Avoid concentrating all hashrate. Compare pool block share, payout construction, software requirements and recovery policy—not just the advertised fee.
New operators can use our XBT DATUM node setup guide und Shrike wallet guide. For pool-selection context, see the XBT/BTCB2 mining guide. Compatible hardware is listed in the BT-Miner BTCB2-Bergbausammlung.
Häufig gestellte Fragen
Is Lazarus freezing XBT withdrawals?
No. The make-good queue is a settlement process for omitted historical coinbase payouts. It is not a wallet-wide or network-wide freeze.
Did miners lose their shares?
Lazarus says the shares remained credited. The problem was that some miners were missing from the original on-chain coinbase split, so the pool must pay them later from the matured pool output.
Can Lazarus pay before the listed maturity height?
Not from the affected coinbase output. Consensus rules prevent that output from being spent before maturity.
Will a make-good be locked for another 180 days?
No. A make-good is a normal transaction output sent after the parent coinbase matures. It does not become a new coinbase output.
Does every miner lose 10%?
No. The adjustment is associated with miners using outdated gateways that create the faulty unsplit payout path. Verify the exact record and current Lazarus policy.
Fazit
The Lazarus make-good queue is both a recovery story and a warning. Public records, precomputed payout details and on-chain settlement give affected miners a way to audit what they are owed. At the same time, the incident proves that a direct-coinbase pool can still develop temporary custody exposure when gateway software constructs the payout incorrectly.
For miners, the immediate job is to verify the queue and update the gateway. For the wider XBT community, the longer-term lesson is to demand version discipline, transparent accounting and tested recovery procedures from every pool claiming a non-custodial design.
Primäre Quellen
- Lazarus live make-good API
- Lazarus Pool source repository and documentation
- Lazarus BLAKE2b unsplit-coinbase advisory
- DATUM BLAKE2b StartOS package documentation
- RATUM gateway and Prime documentation, including owed-block settlement
- Omega Pool gateway requirements and old-version payout warning
- B2Pool coinbase payout and fallback-settlement policy
- Rabid Pool DATUM gateway and payout-capacity documentation
- AlphaPool DATUM payout and block-weight requirements
- Bitcoin Xor DATUM payout documentation
- XBT.live pool directory and Lazarus gateway notice
- XBT.live analysis of the 45-day and 180-day maturity windows
Disclosure: BT-Miners sells the mining hardware linked above. This article is operational analysis, not financial advice or a guarantee of pool payment, profitability, liquidity or software compatibility. Pool policies, software versions and chain conditions can change quickly. Facts and figures were checked October 31, 2026.
