Your Best Solo Share Wasn't a Block: eCash RTT

eCash Real-Time Targeting, known as Heartbeat, is a consensus rule that raises the required mining target for roughly two minutes after every block, then lets it decay back to the published difficulty. A share that beats the difficulty shown on an explorer is only a valid block if it arrives after that decay. This is the single most common reason a solo miner on XEC sees a record share and wins nothing.

Key takeaways

• eCash requires a higher difficulty than the published one for about 115 seconds after each block, at a steady cadence.
• The requirement starts astronomically high and falls as the fifth power of elapsed time. It can never be easier than the standard difficulty.
• Explorers show the difficulty of each block as mined — the floor value. There is no public feed of the live requirement.
• We reproduced the official formula against a production node’s own logs across 15 measurements: maximum deviation 0.002%.
• The steep early ramp that solo miners hit today exists entirely because of the 15 November 2025 upgrade, which added a one-block filter window.

Why did my share beat the network difficulty and not find a block?

A miner wrote to us with a precise and entirely reasonable complaint. They had solved an eCash block with a share of roughly 8.0 billion difficulty against a published network difficulty of about 7.36 billion. Hours later their miner recorded a far better share — roughly 11.87 billion — and nothing happened. They checked every block on the chain since. The published difficulty had stayed between 7.1 and 7.4 billion all night. Under Bitcoin’s rules, that share was a block.

They were right about the numbers and wrong about the rule. On eCash the difficulty an explorer publishes is not the difficulty you have to beat at the moment you submit. It is the floor.

Their 11.87 billion share arrived roughly 100 seconds after the previous block — still inside the ramp. At that moment the network required 14.85 billion, so the share was worth about 80% of what was needed. Fifteen seconds later the ramp cleared, the requirement fell to 7.33 billion, and the exact same share would have won. They did not lack hashrate. They lacked a quarter of a minute.

What is eCash Real-Time Targeting?

Real-Time Targeting activated with the Heartbeat upgrade on 15 November 2024. The problem it solves is specific to minority SHA-256 chains.

eCash shares its algorithm with Bitcoin and Bitcoin Cash, so hashrate moves between them chasing profitability. When eCash difficulty drops, external hashrate floods in and mines several blocks in rapid succession — turbo blocks. The standard difficulty algorithm reacts by raising difficulty; the visiting hashrate leaves; the chain is stranded with a high difficulty and a fraction of the hashrate, producing block gaps that can run for hours. Deposits stall. Confirmations become unpredictable.

Heartbeat attacks the first half of that cycle. By making blocks mined too soon after their predecessor invalid, it removes the reward for burst mining, so the base algorithm never over-corrects in the first place. The design is inspired by Tom Harding’s Real-Time Block Rate Targeting research.

The mechanism only works because of Avalanche. Real-time targeting depends on each node’s own measurement of when a block arrived, which is inherently subjective. Avalanche post-consensus reconciles those subjective views into a single network decision, without touching the block header or Nakamoto consensus.

How is the eCash real-time target calculated?

The rule is implemented in Bitcoin ABC as a parking policy rather than a validity rule. The relevant source lives in src/policy/block/rtt.cpp, and the core formula is stated in the file’s own comment:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K is 6, so the target scales with the fifth power of elapsed time. T is the target spacing for that filter window. The elapsed time is measured from when the node received each previous block header, not from the timestamp written in the header.

The formula is evaluated over five windows simultaneously, and the strictest result wins:

The window lengths are prime numbers with one skipped between successive entries. The source explains why: it is a best-effort attempt to avoid resonant frequencies from chaining a series of filters. The series stops at 17 blocks because further windows no longer change the filter’s selectivity in any meaningful way.

Two properties matter for miners. The lowest target across all windows applies, so the hardest constraint governs. And the result is capped: the real-time target is never higher — never easier — than the standard target. Difficulty can only be pushed up, never down.

Reconstructing the constants from gamma(1 + 1/6) = 0.9277193336 reproduces all five published coefficients to ten significant figures.

How much harder is an eCash block right after the previous one?

This is the table that does not exist anywhere else, computed from the official formula at a steady ten-minute cadence. The multiplier is applied to the difficulty an explorer would publish.

A block found one second after its predecessor would need roughly twenty billion times the published difficulty. Ten seconds in, two hundred thousand times. The curve is brutally steep and then it simply stops: after about 115 seconds the requirement equals the published difficulty exactly, and stays there.

When recent blocks arrived faster than ten minutes, every window starts from a shorter elapsed time and the ramp both starts higher and lasts longer. That is not a side effect. That is the anti-turbo-block mechanism doing its job.

Does the formula match what a real node actually does?

We tested it. Below are the values logged by one of our eCash nodes in the two and a half minutes after a block, alongside the values the published formula predicts using only the block arrival times visible in the same log.

Across all fifteen logged measurements the maximum deviation was 0.002%. The published formula is not an approximation of what nodes do — it is exactly what they do.

One detail is worth pulling out. For the first 99 seconds the binding constraint was the one-block window. Only at 109 seconds did the two-block window take over, and 40 seconds later the standard difficulty took the floor.

What changed on 15 November 2025?

Before that upgrade there were four windows, starting at two blocks. The 15 November 2025 upgrade added the one-block window with its 150-second spacing.

Running both configurations through the formula at a steady ten-minute cadence produces a striking result:

At a normal cadence the four-window configuration produced no ramp at all. It engaged only when blocks were already arriving too fast — which was its narrow purpose. The steep early ramp that a solo miner runs into today, on an otherwise healthy chain, exists entirely because of the one-block window added in November 2025.

If you solo mined eCash before that date and never saw this happen, that is why.

Why doesn’t the difficulty my pool shows match the explorer?

Because on eCash they are different numbers, and the mining software says so.

Bitcoin ABC’s eCash solo mining software reads rtt.nexttarget from each getblocktemplate call, converts it to a difficulty, and — for eCash only — uses that value as the network difficulty it reports and logs. Every other SHA-256 chain uses the difficulty bits from the block header instead.

That single branch explains the behaviour every eCash pool operator sees: after a block arrives, the reported network difficulty is astronomically high, drops by an order of magnitude every ten seconds for about two minutes, and then goes flat at the value an explorer will eventually publish.

Node operators have a second option: compute the target locally from rtt.prevheadertime, rtt.prevbits and rtt.nodetime, all present in the block template. Both routes are documented on the eCash mining page.

What happens to a block that violates the real-time target?

It is parked, not rejected. The node marks it with a policy violation labelled policy-bad-rtt and sets it aside, then Avalanche polling decides whether the rest of the network agrees. If the node is in the minority it flips its position. The block header is untouched throughout, and Nakamoto consensus is not modified.

Running getchaintips on an eCash node shows these alongside the active chain, marked status: parked. On one of our nodes the call returned 262 parked branch tips spanning block heights 940,265 to 960,666 — roughly 20,400 blocks, so about 1.3% of blocks in that range were parked at least once.

That figure is an upper bound on real-time target violations rather than a count of them. eCash parks blocks for several reasons, and Avalanche also parks the losing side of an ordinary fork race. But on a chain where two competing blocks at the same height are rare, a parked-tip rate above one percent tells you the mechanism is active and doing work, not sitting idle.

Does this apply to Bitcoin, Bitcoin Cash, or the other SHA-256 chains?

No. Among SHA-256 chains this behaviour is unique to eCash, because it depends on the Avalanche layer to reconcile subjective timing.

On Bitcoin and Bitcoin Cash, a share above the network difficulty is a block, full stop. If you mine several chains and you are comparing your best-share figures across them, the eCash column is the only one where timing enters the calculation. Our solo mining odds breakdown and the Network Radar both use published difficulty, which is the correct basis for long-run probability — the ramp averages out over time.

How big is the dead zone for a solo miner?

Every share landing before the ramp clears is wasted, no matter how good it is. At a steady cadence:

Roughly one fifth of every block interval is unusable for a share that only just clears the difficulty. Stronger shares clear the ramp sooner, which is why a truly enormous share is almost never wasted.

This does not change your expected return in any way you can act on. It is already reflected in the chain’s actual block production, and therefore in the difficulty itself. Nothing in your miner configuration influences it.

What should a solo miner actually do about this?

For most people, the honest answer is nothing — but read your numbers correctly.

• Your miner’s best-difficulty display is computed locally, the instant the hash is found, before the pool has responded. It records the value whether or not the share was ever going to be valid. It is also an all-time figure that does not reset when you find a block.
• A best-ever share above the published difficulty on eCash is not evidence of a missed or stolen block. If you want to confirm a block exists, look at the coinbase transaction on-chain. On a non-custodial pool your address is written into the coinbase before hashing starts, so a real block is visible in your own name and nobody can move it.
• If you are curious how close you have been, our best share explained article covers how to read those figures, and the odds calculator converts hashrate into realistic expectations. The eCash pool page lists the current difficulty and every regional endpoint, the configuration generator builds the stratum settings, and live block and worker data sits on the pool dashboard.

If you run your own eCash node for solo mining, there is one configuration item that matters. A node needs 17 blocks of recorded header arrival times before it can compute the real-time target. Until it has them it may build templates at too low a difficulty and get its blocks parked. Setting persistrecentheaderstime=1 saves those reference times to disk and reloads them on restart, which closes the gap.

Sources

• eCash mining documentation — the RTT block-template fields, the reference implementation of the target computation, and the published filter coefficients
• Heartbeat Upgrade: A Steady Pulse for eCash — the rationale, the switch-mining problem, and the role of Avalanche post-consensus
• Bitcoin ABC source — src/policy/block/rtt.cpp, containing the formula, the window constants and the parking policy
• eCash solo mining software — how the real-time target becomes the reported network difficulty on eCash

Verification figures in this article were produced by evaluating the published formula against the logs of a live eCash node on 2 August 2026 and comparing the results value by value.