What Is DigiShield?

Proof-of-work blockchains have to solve an awkward problem: as mining hardware joins or leaves the network, the difficulty of finding a valid block has to adjust to keep the block time roughly constant. Get that adjustment wrong, and either blocks slow to a crawl or a chain gets flooded with cheap, fast blocks. DigiShield is DigiByte's answer, and it was influential enough that several other chains later copied it.

The problem: hash-hopping

Many early proof-of-work chains only retargeted difficulty every 2,016 blocks — roughly every two weeks. That's a huge window, and it created an exploit known as multipool hash-hopping: a large mining pool waits for a difficulty drop, points enormous hashrate at the coin the moment it's cheap to mine, extracts a burst of fast, easy blocks, and then leaves before the next adjustment. The coin's regular, smaller miners are left facing a difficulty calibrated for hashrate that's no longer there, and the network grinds to a crawl until the slow adjustment finally catches up.

DigiShield's fix: retarget every block

DigiShield recalculates difficulty after every single block instead of every two weeks. It looks at the timestamps of the most recent blocks and moves the difficulty target up or down in near real time. A flood of hashrate gets absorbed within a block or two rather than persisting for days, which makes hash-hopping largely unprofitable — the difficulty a hopper faces adapts before they can extract much value from it. DigiByte introduced this mechanism in 2014, directly in response to hash-hopping attacks it was suffering at the time, and it kept DigiByte's roughly 15-second block time stable through some genuinely volatile hashrate periods.

The approach proved influential well beyond DigiByte. Other proof-of-work chains — including Dogecoin, Zcash, and Ubiq — later adopted similar per-block or near-per-block difficulty retargeting of their own, after watching the same hash-hopping exploit hit their own networks.

DigiShield and MultiShield, working together

DigiShield solves the "too much or too little total hashrate" problem. It has a sibling mechanism, MultiShield, that solves a different problem: keeping the balance between DigiByte's five separate mining algorithms fair, so no single algorithm's hardware market can crowd out the other four. Where DigiShield reacts to swings in total hashrate over time, MultiShield independently retargets each of DigiByte's five algorithms so each keeps producing roughly its fair one-fifth share of blocks. You can read the full breakdown of how that works in DigiByte's five mining algorithms.

Together, the two mechanisms give DigiByte a layered defense: DigiShield against volatile total hashrate, MultiShield against any one algorithm dominating. That layered defense is also part of why a sustained 51% attack on DigiByte is significantly harder to pull off than on a single-algorithm chain — a topic covered in depth in what a 51% attack actually requires.

Why real-time retargeting still matters today

Hashrate volatility didn't go away once hash-hopping stopped being profitable — mining hardware still migrates toward whichever coin is momentarily most profitable to mine, and total network hashrate on any given algorithm can shift meaningfully within hours. DigiShield's per-block response means DigiByte's block time stays close to 15 seconds through those swings, rather than drifting for days at a time the way a slow-retargeting chain would.

This matters more than it might first appear. A block time that swings wildly makes fee estimation unreliable, makes wallets show inconsistent confirmation times, and makes any service built on top of the chain — an exchange crediting deposits, a merchant waiting for payment, DigiDollar recomputing collateral every block — harder to reason about. By keeping the interval between blocks close to its 15-second target no matter what hashrate does, DigiShield keeps that whole downstream stack predictable.

Verify it yourself

Difficulty adjustments aren't a black box — every block header records the difficulty target that produced it. Open a recent run of blocks in the block explorer and you can watch the target shift block to block as real hashrate moves, rather than sitting fixed for two weeks at a time.