Why This Layer Gets Ignored

Most Handshake content focuses on what you can build on top — TLDs, namespaces, DANE security, NFT protocols. That content matters. But Handshake's entire value proposition rests on one claim: nobody controls the root zone. The mechanism that makes that claim true is proof-of-work mining. If you don't understand the mining layer, you don't fully understand why Handshake is hard to attack, censor, or shut down.

This post teaches the mining layer from the ground up — how blocks are found, what pools do, how merged mining works, and why the distribution of hashrate across pools is something every serious HNS participant should watch.

Part 1: How Proof-of-Work Secures Handshake

Handshake uses a proof-of-work consensus mechanism — the same fundamental model as Bitcoin. To add a new block to the chain, a miner must find a number called a nonce such that when combined with the block's data and run through a hash function, the output meets a specific difficulty target.

The hash function Handshake uses is a combination of Blake2b and SHA3. The output is a 256-bit number. The network sets a difficulty target — a threshold the output must fall below. Because hash functions produce effectively unpredictable outputs, the only way to find a valid nonce is to try billions of them until one works.

Block Header:
  Previous block hash
  Merkle root of transactions
  Timestamp
  Difficulty target
  Nonce  ← miner varies this until output < target

Hash(block_header) → must be below target to be valid

The difficulty adjusts every 72 blocks (roughly 12 hours) so that blocks are found on average every 10 minutes. If blocks come in too fast, difficulty increases. Too slow, it decreases. This mechanism keeps the chain's pace stable regardless of how much mining hardware joins or leaves the network.

What this means for security: To rewrite the chain's history — for example, to change who owns a TLD — an attacker would need to redo all the proof-of-work from the target block forward, faster than the honest network continues building. With significant global hashrate behind HNS, this becomes computationally and economically prohibitive. The chain's history is protected not by a server, a company, or a policy — but by accumulated physical work.

This is why Handshake's ownership model is fundamentally different from ICANN: owning a TLD on HNS means your record is secured by the same force that secures Bitcoin transactions.

Part 2: Why Solo Mining Is Practically Impossible Today

In Handshake's early days, a single GPU could find blocks with some regularity. As the network has grown, the total hashrate — the combined computational power of all miners — has increased substantially. Today, the probability that any single mining machine finds a block in a given 10-minute window is very small.

Think of it like a lottery where tickets are drawn every 10 minutes and you hold one ticket out of millions. You might go weeks or months without winning, even while spending real electricity. This variance problem is why mining pools exist.

Part 3: What a Mining Pool Actually Does

A mining pool is a coordination server that distributes work across many miners and shares block rewards proportionally when any participant finds a valid block.

Here's how it works mechanically:

1. The pool operator runs a full HNS node (hsd) and assembles candidate blocks — choosing which transactions to include and setting the coinbase (reward) address to the pool's wallet.

2. The pool issues "shares" to individual miners. A share is a proof-of-work solution that meets a lower difficulty target than the actual network requires. Finding a share is much easier than finding a real block — miners find them constantly. Shares prove the miner is doing real work without requiring them to actually win a block.

3. When a miner finds a nonce that meets the actual network difficulty, it submits it to the pool. The pool broadcasts this valid block to the HNS network and claims the block reward.

4. The reward is split among all miners who contributed shares in that round, proportional to their contributed work.

Pool operator assembles candidate block
  → distributes work via Stratum protocol

Miner A → submits 1,000 shares
Miner B → submits   400 shares
Miner C → submits   600 shares
                  ─────────────
Total:            2,000 shares

Miner B finds a valid block → Pool broadcasts it

Block reward: 2,000 HNS (example)
  → Miner A receives 1,000 HNS (50%)
  → Miner B receives   400 HNS (20%)
  → Miner C receives   600 HNS (30%)
  → Pool fee deducted from totals (typically 1–3%)

The pool smooths out variance. Instead of waiting months for a solo block and earning nothing in the meantime, miners receive small, consistent payouts every time the pool finds a block.

Common Payout Schemes

PPS (Pay Per Share): The miner gets a fixed amount per share regardless of whether the pool finds a block that round. The pool absorbs the variance risk. Predictable for miners; the pool operator takes on more risk.

PPLNS (Pay Per Last N Shares): The miner is paid proportionally from the actual block reward when found. More variance for the miner, but more directly aligned with pool performance. Common in HNS pools.

SOLO via pool infrastructure: The pool provides Stratum connectivity and node infrastructure, but the miner keeps the full block reward if they personally find a valid block. Maximum variance, maximum upside — suited to miners with significant hashrate.

Part 4: Merged Mining — How HNS Leverages Bitcoin's Hashrate

This is one of the most technically interesting aspects of Handshake, and one almost nobody explains clearly.

Merged mining allows a miner to simultaneously mine two different proof-of-work blockchains with the same computational work. Handshake supports merged mining with Bitcoin — meaning a Bitcoin miner can mine HNS blocks at zero additional energy cost.

How is this possible without breaking either chain's security? Through a structure called Auxiliary Proof of Work (AuxPoW).

A Bitcoin miner's hardware performs its normal SHA256d hashing work. Inside each candidate Bitcoin block, there is a coinbase transaction with an extra data field. Merged miners embed a cryptographic commitment to the HNS block header hash inside this field. When the miner performs its SHA256d work for Bitcoin, the same work is simultaneously valid for Handshake — as long as the resulting hash meets HNS's difficulty target.

Bitcoin block header
  └── coinbase transaction
        └── extra nonce / data field
              └── [Commitment to HNS block header hash]

Bitcoin miner performs normal SHA256d work:

If hash(Bitcoin block) < Bitcoin target → valid Bitcoin block
If hash(Bitcoin block) < HNS target     → also a valid HNS block
  → AuxPoW proof submitted to HNS network alongside the HNS block

The HNS network verifies the merge-mined block by checking that:

  1. The HNS block header commitment appears correctly in the Bitcoin coinbase
  2. A valid Merkle proof links that coinbase to the Bitcoin block header
  3. The Bitcoin block's hash meets HNS's current difficulty target

This design means Handshake inherits a portion of Bitcoin's enormous global hashrate without those miners needing any additional hardware or electricity. For an attacker trying to overwhelm the HNS chain, this is a meaningful barrier: they compete against miners who are simultaneously securing Bitcoin.

It also means that the most competitive HNS mining pools are those that offer merged mining alongside Bitcoin pools — giving their miners dual revenue from the same work. This is a core reason why Bitcoin and Handshake are more deeply connected at the infrastructure level than most people realize.

Part 5: Pool Distribution and Why It's a Network Health Metric

Here is where the technical understanding translates into something every HNS participant should care about.

When a mining pool finds a block, it is the pool operator — not the individual miners — who decides which transactions to include, which name registrations to process, and which rules to follow. The pool assembles the block. The miners provide the hashrate that makes the block valid.

This means pool concentration is a proxy for control concentration.

If a single pool controls the majority of the network's hashrate, it acquires theoretical leverage over the chain:

  • Transaction censorship: A dominant pool could choose to exclude specific name registrations or TLD transfers from every block it produces — delaying those transactions indefinitely as long as it maintains majority hashrate.
  • Chain reorganization: A pool with majority hashrate could theoretically mine a longer competing chain and cause recent blocks to be orphaned, reversing transactions that appeared confirmed.
  • Selfish mining: A large pool can withhold valid blocks strategically, wasting honest miners' work and increasing its own effective share of rewards.

In practice, executing these attacks would be economically irrational — it would destroy confidence in HNS, crash the value of the pool operator's holdings, and cause miners to leave for competing pools immediately. But theoretical capability matters for a system that claims to be permissionless. The promise of Handshake is that no single entity controls the naming root. A pool approaching majority hashrate is, at minimum, a concentration of temporary leverage that the ecosystem should monitor.

What Healthy Pool Distribution Looks Like

Pool A    ████████████████████  22%
Pool B    ████████████████      18%
Pool C    ██████████████        15%
Pool D    ████████████          13%
Pool E    ████████              10%
Others    ██████████████████    22%

No single pool dominates. Multiple independent operators share the work. The chain's fate is distributed across entities with competing interests — which means no one entity can unilaterally alter the rules.

What a Concerning Distribution Looks Like

Pool A    ████████████████████████████████████████████  52%
Pool B    ████████████          14%
Pool C    ████████              10%
Others    ████████████████████  24%

One pool above 50% is a warning sign. It does not mean the chain is under active attack — most large pools are run by honest operators with strong economic reasons to behave correctly. But it means the network's censorship resistance depends on that pool operator's continued good faith rather than the system's structural design.

This is why tracking pool distribution over time — not just as a snapshot but as a trend — is one of the most meaningful things the HNS community can do for ecosystem health. When hashrate concentrates, miners should be encouraged to redistribute to smaller pools. When a new pool launches, it benefits the entire network even if it attracts hashrate away from an established operator.

Part 6: How to Read Pool Data

When reviewing HNS mining pool metrics, the key numbers to understand:

Hashrate share — What percentage of total network hashrate a pool controls, estimated from the proportion of recent blocks it has found. Usually calculated over a rolling window of 144 blocks (roughly 24 hours) to reduce short-term variance noise.

Blocks found — The raw count of blocks mined by a pool in a given period. Directly observable from the chain with no estimation. Over long enough windows, this converges to true hashrate share.

Pool fee — The percentage of each block reward the operator retains before distributing to miners. Typically 1–3% for competitive HNS pools. Higher fees reduce miner take-home; lower fees attract more miners.

Merged mining support — Whether the pool supports simultaneous Bitcoin merged mining. For Bitcoin miners in particular, this is significant: it means earning HNS revenue on top of BTC from the same hardware work.

Minimum payout threshold — The minimum HNS balance a miner must accumulate before the pool sends a payout transaction. Lower thresholds are better for small miners; higher thresholds reduce on-chain transaction overhead for the pool.

Luck — A pool's luck metric compares blocks actually found to blocks statistically expected given its hashrate. A pool at 110% luck found more blocks than expected (short-term good fortune). A pool at 80% luck found fewer. Over time, luck converges to 100%. Single-day luck figures are noise; week-over-week trends are signal.

Why This Matters Beyond Mining

Understanding the mining layer isn't only for miners. It matters for everyone building on Handshake because mining is what makes all the higher-level properties real rather than theoretical.

The banking security architecture works because a bank's TLD record cannot be altered without a transaction confirmed by the honest majority of miners. The real estate NFT model works because property ownership is recorded in a chain secured by proof-of-work, not a database secured by a company's server. The Mars-ready DNS architecture works because the chain's security is physical and global — not dependent on any single jurisdiction or institution.

Every one of those properties is downstream of mining. And the health of the mining ecosystem — specifically whether hashrate is distributed across many independent pools or concentrated in one — determines whether those properties are structural guarantees or assumptions about good behavior.

A Handshake TLD is only as sovereign as the chain that records it. The chain is only as decentralized as the pools that secure it.

FAQ

Do I need specialized hardware to mine HNS?

Handshake's hashing algorithm (Blake2b + SHA3) is GPU-mineable, unlike Bitcoin's SHA256d which is dominated by ASICs. Consumer GPUs can participate, though profitability depends heavily on electricity cost, current HNS price, and network difficulty. For most participants, joining a pool with available GPU hardware is the realistic starting point; competitive solo mining is not practical without significant hashrate.

What is the HNS block reward and does it change over time?

Handshake has a decreasing block reward schedule. Unlike Bitcoin's sharp halvings, HNS uses a smoother reduction curve — the reward decreases gradually over time toward a fixed total supply. Additionally, Handshake reserved a portion of its initial supply for an airdrop to open source developers, distributed over the first years of the network. Current block reward figures and the remaining supply schedule are visible on HNS block explorers.

Can a pool's block share differ significantly from its hashrate share in the short term?

Yes. Mining is probabilistic — a pool with 20% of network hashrate might find 30% of blocks in a given day by chance, or only 12%. This is normal variance. Over windows of a week or more, actual blocks found converges reliably to true hashrate share. Responsible pool tracking uses rolling averages of at least 144 blocks (24 hours), not single-day snapshots, to estimate true hashrate distribution.

What stops a large pool from censoring my TLD registration?

If a pool controlling majority hashrate chose to exclude specific transactions, it could delay them — but not permanently block them. The honest minority of miners would still include those transactions in their blocks; the censored transactions would take longer to confirm but would eventually go through as long as some honest hashrate exists. More practically, such behavior would be visible on-chain, would destroy the pool's reputation immediately, and would cause miners to withdraw hashrate rapidly — eliminating the pool's dominance. The economics of censorship are strongly self-defeating for any pool operator who values their business.

What's the difference between a mining pool and a mining farm?

A mining farm is physical infrastructure — servers, GPUs, power, cooling — owned by one entity. A mining pool is a coordination protocol that aggregates work from many farms and individual miners across the world. A farm points its hashrate at a pool via the Stratum protocol. The farm's owner decides which pool to use; the pool operator sees hashrate from many farms without owning any of the hardware itself. Large farms sometimes run their own private pools, combining both roles.

How does merged mining affect HNS security — does it make the chain dependent on Bitcoin?

Merged mining adds hashrate to HNS; it does not create a dependency. If Bitcoin miners stopped merge mining HNS entirely, the HNS chain would continue operating — difficulty would adjust downward to match the remaining native HNS hashrate, and blocks would continue to be found on schedule. The chain's security would decrease proportionally, but it would not stop. Merged mining is additive to HNS security, not a requirement for it.

Architecture and original research by NIHON — Handshake Infrastructure & Web3 Identity, June 2026. To resolve Handshake domains natively, download the SkyInclude Browser. For more on building with HNS, explore LearnHNS.