WTEMA

Think of cruise control on a hilly road. It doesn’t wait ten minutes and then slam the pedal. It feels every small slowdown and eases the throttle a little, all the time.

Pearl’s difficulty works the same way. After every block, every node looks at how long that block took, compares it with 194 seconds, and nudges the target: a little easier if the block was slow, a little harder if it was quick. The rule is called WTEMA, short for “weighted-target exponential moving average”.

Each nudge is tiny. Together they hold the pace near one block every 194 seconds, whatever the miners do.

Try it

Make the mining power jump or crash, and watch block times and the target react, block by block. Compare it with Bitcoin’s once-every-2,016-blocks rule.

What is the rule?

Call the previous block’s target X and its solve time t: its timestamp minus its own parent’s. The next block’s target is

In words: every second the last block ran late grows the target by one part in 604,800. Every second it ran early shrinks it by the same. A block right on 194 seconds changes nothing.

Those two numbers are Pearl’s parameters: TargetTimePerBlock = 3 minutes 14 seconds, and WTEMAHalfLife = 168 hours, one week.

A worked example with real numbers

Start at the chain tip on 20 October 2026: block 130,827, bits 0x176af3a6. Suppose the next block takes 300 seconds. Pearl’s own code gives:

1. Decode the old target

   0x176af3a6 → 0x6af3a6 × 2¹⁶⁰ = 10,243,942,661,363,391,425,244,085,692,626,643,778,542,165,820,901,949,440.

2. Compute the adjustment

   (300 − 194) × old ÷ 604,800, rounded down = 1,795,400,003,479,694,925,720,689,622,054,272,884,466,715,570,462,312.

3. Add it

   New target = 10,245,738,061,366,871,120,169,806,382,248,698,051,426,632,536,472,411,752: the old one × 1.00017526.

4. Re-encode as bits

   Keep the top three bytes: 0x176af872. Difficulty goes from 40,157,376.49 to 40,150,342.21.

Here are five steps in a row from the same start, again computed with Pearl’s code:

Which block’s time counts?

The parent’s. A block’s required bits depend only on its parent’s bits and its parent’s solve time, its timestamp minus the grandparent’s. Its own timestamp plays no part. That’s a one-block lag.

Here are six real consecutive blocks. Feed each parent’s bits and solve time into the formula and you get exactly the bits the chain carries:

One consequence: two competing blocks at the same height, built on the same parent, always need exactly the same bits. That matters for choosing between branches.

Why is the “half-life” really a time constant?

The code calls 604,800 seconds WTEMAHalfLife, but its own comment calls it “the time constant for the WTEMA exponential filter”. The comment is right: it behaves as a time constant, not a half-life.

Each block moves the target by a factor (1 + (t − 194) ÷ 604,800). Multiply many of those together and the result is close to

So one full week of accumulated lateness grows the target by e ≈ 2.72, not 2. It doubles after ln 2 ≈ 0.693 weeks: about 4.85 days of total lateness. The genesis message’s “WTEMA 3m14s 7d” names the same two parameters: 194 seconds and seven days.

Pearl’s code confirms it. With every block 388 seconds apart (each 194 seconds late), after 2,161 blocks, 4.85 days of lateness, the target has grown ×1.96. Without rounding it would be ×2.00.

Are there limits on a single step?

No clamp in the formula. Two other rules bound it instead:

• Tightening is capped by the timestamp rule. A block must be at least 1 second after its parent, so t ≥ 1 and the biggest single drop is ×(1 − 193 ÷ 604,800) = ×0.99968. Difficulty can rise at most about 0.032% per block.
• Loosening has no cap except the limit 2²⁰⁸ − 1. A block found a full week after its parent roughly doubles the target (×1.99968). The 5-minute future limit stops a miner from faking that.

The tightening cap explains Pearl’s slow start. Even with every block 1 second apart, climbing from difficulty 1 to 40 million takes at least about 54,857 blocks.

Does rounding matter?

A little, and always in the same direction. The division rounds down, and re-encoding as bits rounds down again, keeping only the top two or three bytes of the target. Both push the target smaller, so difficulty drifts slightly up.

You can see it at mantissa 0xfffe, where one unit of the mantissa is a big step (1 ÷ 65,534 of the target):

One second early knocks the target down; it takes ten seconds late to push it up. At today’s mantissa 0x6af3a6, a unit is 1 ÷ 7,009,190 of the target and one second moves it by about 11.6 units, so the bias is tiny.

The bias grows when the mantissa is small. In the 388-second test above, after 3,118 blocks the target had grown ×2.644 instead of the ideal ×2.718: once the growing target pushed the exponent up a step (to bits like 0x1800d1a7), the compact form kept only about two significant bytes for the rest of the run.

How did it behave at launch?

There was no special start-up mode. Genesis used the easiest bits, 0x1b00ffff; block 1 reused them, and WTEMA ran from block 2.

The first blocks came as fast as the rules allow: blocks 1 to 5 are exactly 1 second apart. Each one tightened the target by the maximum step (block 2 got 0x1b00ffea, block 3 0x1b00ffd5). From there, the climb:

Blocks reached about 194-second spacing around blocks 70,000 to 80,000, in early June 2026. On 20 October 2026 the average over the last 144 blocks was 174.3 seconds, a little faster than target. WTEMA reacts over days, not instantly, so while mining power keeps growing, blocks tend to run a little fast. The live average is 174.3 seconds.

How is this different from Bitcoin?

t := lastNode.Timestamp() - parentNode.Timestamp()
T := int64(c.ChainParams().TargetTimePerBlock / time.Second)   // 194
halfLife := int64(c.ChainParams().WTEMAHalfLife / time.Second) // 604,800
oldTarget := CompactToBig(lastNode.Bits())
adjustment := new(big.Int).Mul(big.NewInt(t-T), oldTarget)
adjustment.Div(adjustment, big.NewInt(halfLife))
newTarget := new(big.Int).Add(oldTarget, adjustment)
// clamp to PowLimit, and to at least 1, then:
newTargetBits := BigToCompact(newTarget)

const floorDiv = (a, b) => (a % b !== 0n && (a < 0n) !== (b < 0n) ? a / b - 1n : a / b);
const next = (oldTarget, t) => oldTarget + floorDiv(BigInt(t - 194) * oldTarget, 604800n);